个人中心
文章发布
退出
作者热门文章
- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
26
4
CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章pgsql之pg_stat_replication的使用详解由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.
pg_stat_replication是一个视图，主要用于监控一个基于流的设置，建议您 注意系统上称作pg_stat_replication的视图。（注：当前版本为pg 10.0,10.0以下版本，字段名会有差异）此视图包含以下信息:
\d pg_stat_replication 。
每个字段代码的含义:
• pid 这代表负责流连接的wal_sender进程的进程ID。如果您在您的操作系统上检查您进程表，您应该会找到一个带有那个号码的PostgreSQL进程.
• usesysid 每个内部用户都有一个独一无二的编号。该系统的工作原理很像UNIX。 usesysid 是 (PostgreSQL) 用户连接到系统的唯一标识符.
• usename (不是用户名, 注意少了 r)它存储与用户相关的 usesysid 的名字。这是客户端放入到连接字符串中的东西.
• application_name这是同步复制的通常设置。它可以通过连接字符串传递到master.
• client_addr它会告诉您流连接从何而来。它拥有客户端的IP地址.
• client_hostname除了客户端的IP，您还可以这样做，通过它的主机名来标识客户端。您可以通过master上的postgresql.conf中的log_hostname启用DNS反向查找.
• client_port这是客户端用来和WALsender进行通信使用的TPC端口号。 如果不本地UNIX套接字被使用了将显示-1.
• backend_start它告诉我们slave什么时间创建了流连接.
• state此列告诉我们数据的连接状态。如果事情按计划进行，它应该包含流信息.
• sent_lsn这代表发送到连接的最后的事务日志的位置.
• write_lsn这是写到standby系统磁盘上最后的事务日志位置.
• flush_lsn这是被刷新到standby系统的最后位置。（这里注意写和刷新之间的区别。写并不意味着刷新 。） 。
• replay_lsn这是slave上重放的最后的事务日志位置.
• sync_priority这个字段是唯一和同步复制相关的。每次同步复制将会选择一个优先权 —sync_priority—会告诉您选择了那个优先权.
• sync_state最后您会看到slave在哪个状态。这个状态可以是 。
async, sync, or potential。当有一个带有较高优先权的同步slave时，PostgreSQL会把slave 标记为 potential.
在这个系统视图中每个记录只代表一个slave。因此，可以看到谁处于连接状态，在做什么任务。pg_stat_replication也是检查slave是否处于连接状态的一个好方法.
上面说到pid代表负责流连接的wal_sender进程的进程ID，我们在机器上通过ps命令查看该进程的状态
ps -aux|grep 8225 。
在Linux上我们可以看到那个进程不仅有自己的作用 (在这种情况下, wal_sender)，而且还带有终端用户的名字以及相关的网络连接信息。在上图中我们可以看到已经有人从192.168.47.127（对应pg_stat_replication的client_addr字段）通过51519(对应pg_stat_replication的client_port字段）)端口连接到了master.
bonus:
上面我们提到replay_lsn是slave上重放的最后的事务日志位置.
pg_current_wal_lsn（）函数的作用是获取当前的wal log的写位置.
pg_wal_lsn_diff()函数的作用是计算两个wal日志之间的差距.
所以我们可以通过下面的方法获取高可用架构下从库的复制延迟情况:
|
1
2
3
4
5
6
7
8
9
|
SELECT
pg_wal_lsn_diff(A .c1, replay_lsn) /(1024 * 1024)
AS
slave_latency_MB
FROM
pg_stat_replication,
pg_current_wal_lsn()
AS
A(c1)
WHERE
client_addr=
'%s'
and
application_name =
'%s'
ORDER
BY
slave_latency_MB
LIMIT 1;
|
补充：PostgreSQL pg_stat_replication sync_state introduce 。
PostgreSQL 9.2引入同步复制后, pg_stat_replication的sync_state列有3种状态. 。
sync 。
async 。
potential 。
分别代表同步standby, 异步standby, 可升级为同步的standby. 。
状态来自以下函数 : pg_stat_get_wal_senders 。
[测试] 。
环境
1个 primary, 3个 standby. 。
。
primary配置 。
|
1
2
|
postgresql.conf
synchronous_standby_names =
'test1,test2,test3'
|
standby1配置 。
|
1
|
primary_conninfo =
'application_name=test1 host=127.0.0.1 port=1999 user=postgres keepalives_idle=60'
|
standby2配置 。
|
1
|
primary_conninfo =
'application_name=test2 host=127.0.0.1 port=1999 user=postgres keepalives_idle=60'
|
standby3配置 。
|
1
|
primary_conninfo =
'application_name=test3 host=127.0.0.1 port=1999 user=postgres keepalives_idle=60'
|
primary查询 。
|
1
2
3
4
5
6
7
|
digoal=#
select
pid,application_name,client_addr,sync_state
from
pg_stat_replication;
pid | application_name | client_addr | sync_state
------+------------------+-------------+------------
6311 | test1 | 127.0.0.1 | sync
6321 | test2 | 127.0.0.1 | potential
6391 | test3 | 127.0.0.1 | potential
(3
rows
)
|
如果sync节点挂掉, 按synchronous_standby_names的顺序, 第一个potential节点会变成sync状态. 。
|
1
2
3
4
5
6
7
|
pg_ctl stop -m fast -D /pgdata11999
digoal=#
select
pid,application_name,client_addr,sync_state
from
pg_stat_replication;
pid | application_name | client_addr | sync_state
------+------------------+-------------+------------
6564 | test2 | 127.0.0.1 | sync
6568 | test3 | 127.0.0.1 | potential
(2
rows
)
|
当test1重新起来后又会变成sync状态. 。
|
1
2
3
4
5
6
7
8
9
|
pg93@db-172-16-3-33-> pg_ctl start -D /pgdata11999
server starting
digoal=#
select
pid,application_name,client_addr,sync_state
from
pg_stat_replication;
pid | application_name | client_addr | sync_state
------+------------------+-------------+------------
6564 | test2 | 127.0.0.1 | potential
6605 | test1 | 127.0.0.1 | sync
6568 | test3 | 127.0.0.1 | potential
(3
rows
)
|
。
primary配置 。
|
1
|
synchronous_standby_names =
'test1,test2'
|
standby1配置不变 。
standby2配置不变 。
standby3配置不变 。
primary查询 。
|
1
2
3
4
5
6
7
|
digoal=#
select
pid,application_name,client_addr,sync_state
from
pg_stat_replication;
pid | application_name | client_addr | sync_state
------+------------------+-------------+------------
6470 | test1 | 127.0.0.1 | sync
6472 | test3 | 127.0.0.1 | async
6474 | test2 | 127.0.0.1 | potential
(3
rows
)
|
test3变成异步了. 因为test3没有配置在primary的synchronous_standby_names 中. 。
。
primary配置 。
synchronous_standby_names = 'test1' 。
standby1配置不变 。
standby2配置不变 。
standby3配置不变 。
primary查询 。
|
1
2
3
4
5
6
7
|
digoal=#
select
pid,application_name,client_addr,sync_state
from
pg_stat_replication;
pid | application_name | client_addr | sync_state
------+------------------+-------------+------------
6519 | test2 | 127.0.0.1 | async
6521 | test3 | 127.0.0.1 | async
6523 | test1 | 127.0.0.1 | sync
(3
rows
)
|
test2,test3变成异步了. 因为test2,test3没有配置在primary的synchronous_standby_names 中. 。
1. src/backend/replication/walsender.c 。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
/*
*
Returns
activity
of
walsenders, including pids
and
xlog locations sent
to
* standby servers.
*/
Datum
pg_stat_get_wal_senders(PG_FUNCTION_ARGS)
{
...略
/*
* More easily understood version
of
standby state. This
is
purely
* informational,
not
different
from
priority.
*/
if (sync_priority[i] == 0)
values
[7] = CStringGetTextDatum(
"async"
);
else
if (i == sync_standby)
values
[7] = CStringGetTextDatum(
"sync"
);
else
values
[7] = CStringGetTextDatum(
"potential"
);
...略
|
以上为个人经验，希望能给大家一个参考，也希望大家多多支持我。如有错误或未考虑完全的地方，望不吝赐教.
原文链接：https://blog.csdn.net/qq_35462323/article/details/101351387 。
最后此篇关于pgsql之pg_stat_replication的使用详解的文章就讲到这里了,如果你想了解更多关于pgsql之pg_stat_replication的使用详解的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。
26
4
0
我是一名优秀的程序员,十分优秀！