目录

PostgreSQL实战之物理复制和逻辑复制（四）

4 流复制监控

4.1 pg_stat_replication

4.2 监控主备延迟

4.3 pg_stat_wal_receiver

---

PostgreSQL实战之物理复制和逻辑复制（四）

4 流复制监控

4.1 pg_stat_replication

        主库上主要监控WAL发送进程信息，pg_stat_replication视图显示WAL 发送进程的详细信息，这个视图对于流复制的监控非常重要，前一小节测试写性能过程中此视图的一个时间点数据如下所示：

postgres=#SELECT *  FROM pg_stat_replication ;
-[RECORD 1 ]--—-----+-—----------------------
pid                 |  7683
usesysid            |  16384
usename             |  repuser
application_name    |  node2
client_addr         |  192.168.28.75
client_hostname     |  
client_port         |  57870
backend_start       |  2017-09-05 11:50:31.629468+08
backend_xmin        |  
state               |  streaming          
sent_lsn            |  3/643CB568 
write_lsn           |  3/643CB568
flush_lsn           |  3/643CB488
replay_lsn          |  3/643CB030
write_lag           |  00:00:00.000224
flush_lag           |  00:00:00.001562
replay_lag          |  00:00:00.006596
sync_priority       |  1
sync_state          |  sync

视图中的主要字段解释如下:

pid: WAL发送进程的进程号。
usename: WAL发送进程的数据库用户名。
application_name :连接WAL发送进程的应用别名，此参数显示值为备库recovery.conf配置文件中primary_conninfo参数application_name选项的值。
client_addr:连接到WAL发送进程的客户端IP地址，也就是备库的IP。backend_start: WAL发送进程的启动时间。
state:显示WAL发送进程的状态，startup表示WAL进程在启动过程中; catchup表示备库正在追赶主库;streaming表示备库已经追赶上了主库，并且主库向备库发送WAL日志流，这个状态是流复制的常规状态;backup表示通过pg_basebackup正在进行备份; stopping表示 WAL发送进程正在关闭。
sent_lsn: WAL发送进程最近发送的WAL日志位置。
write_Isn :备库最近写入的WAL日志位置，这时WAL日志流还在操作系统缓存中，还没写入备库 WAL日志文件。
flush_Isn:备库最近写入的WAL日志位置，这时WAL日志流已写入备库WAL日志文件。replay_lsn:备库最近应用的WAL日志位置。
write_lag :主库上WAL日志落盘后等待备库接收WAL日志(这时WAL日志流还没写入备库 WAL日志文件，还在操作系统缓存中）并返回确认信息的时间。
flush_lag:主库上WAL日志落盘后等待备库接收WAL日志(这时WAL日志流已写入备库WAL日志文件，但还没有应用WAL日志）并返回确认信息的时间。replay_lag:主库上WAL日志落盘后等待备库接收WAL日志(这时WAL日志流已写入备库WAL日志文件，并且已应用WAL日志）并返回确认信息的时间。
sync_priority:基于优先级的模式中备库被选中成为同步备库的优先级，对于基于quorum的选举模式此字段则无影响。
sync_state:同步状态，有以下状态值，async表示备库为异步同步模式; potential表示备库当前为异步同步模式，如果当前的同步备库宕机，异步备库可升级成为同步备库;sync表示当前备库为同步模式;quorum表示备库为quorum standbys 的候选。

4.2 监控主备延迟

同步流复制和异步流复制主备库之间的延迟是客观存在的，事实上当流复制主库、备库机器负载较低的情况下主备延迟通常能在毫秒级，数据库越繁忙或数据库主机负载越高主备延迟越大，有两个维度衡量主备库之间的延迟:通过WAL延迟时间衡量，通过WAL日志应用延迟量衡量，下面详细介绍。
方式一：通过WAL延迟时间衡量
WAL的延迟分为write延时、flush延时、replay延时，分别对应pg_stat_replication的write_lag、flush_lag、replay_lag字段，上一节已经详细解释了这三个字段，通过备库WAL日志接收延时和应用延时判断主备延时，在流复制主库上执行如下SQL:

postgres=# SELECT pid, usename,client_addr,state,write_lag,flush_lag, replay_lag
           FROM pg_stat_replication;
-[ RECORD 1 ]—---------------
pid         | 7683
usename     | repuser
client_addr | 192.168.28.75
state       | streaming
write_lag   | 00:00:00.000997
flush_lag   | 00:00:00.002008
replay_lag  | 00:00:00.002916

对于一个有稳定写事务的数据库，备库收到主库发送的WAL日志流后首先是写入备库主机操作系统缓存，之后写人备库WAL日志文件，最后备库根据WAL日志文件应用日志，因此这种场景下write_lag、flush_lag 和 replay_lag大小关系如下所示:
replay_lag > flush_lag > write_lag
以上查询中flush_lag时间为0.2008毫秒，replay_lag时间为0.2916毫秒,replay_lag延时大于flush_lag延时很好理解，因为只有备库接收的WAL日志流写入WAL日志文件后才能应用WAL，因此replay_lag要大于flush_lag。
write_lag、flush_lag、replay_lag 为 PostgreSQL10版本新增字段，10版本前pg_statreplication视图不提供这三个字段，但是也有办法监控主备延时，在流复制备库执行以下SQL：

postgres=# SELECT EXTRACT(SECOND FROM now ()- pg_last_xact_replay_timestamp());
    date_part
----------------
    0.002227
( 1 row)

pg_last_xact_replay_timestamp函数显示备库最近WAL日志应用时间，通过与当前时间比较可粗略计算主备库延时，这种方式的优点是即使主库宕掉，也可以大概判断主备延时。缺点是如果主库上只有读操作，主库不会发送WAL日志流到备库，pg_last_xact_replay_timestamp 函数返回的结果就是一个静态的时间，这个公式的判断结果就不严谨了。

方式二：通过WAL日志应用延迟量衡量
通过流复制备库WAL的应用位置和主库本地WAL写入位置之间的WAL日志量能够准确判断主备延时,在流复制主库执行以下SQL:

pg_current_wal_lsn 函数显示流复制主库当前WAL日志文件写入的位置，pg_wal_Isn_diff 函数计算两个WAL日志位置之间的偏移量，返回单位为字节数，以上内容显示流复制备库WAL的 write延迟560字节，flush延迟896字节，replay延迟1272字节，这种方式有个缺点，当主库宕掉时，此方法行不通。
方式三：通过创建主备延时测算表方式
这种方法在主库上创建一张主备延时测算表，并定时往表插入数据或更新数据，之后在备库上计算这条记录的插入时间或更新时间与当前时间的差异来判断主备延时，这种方法不是很严谨，但很实用，当主库宕机时，这种方式依然可以大概判断出主备延时。

4.3 pg_stat_wal_receiver

pg_stat_replication视图显示WAL发送进程的详细信息，WAL接收进程也有相应的视图显示详细信息，如下所示:

postgres=# SELECT * FROM pg_stat_wal_receiver;
-[ RECORD 1 ]---------+-----------------
pid                   |  22573
status                |  streaming
receive_start_lsn     |  3/2D000000
receive_start_tli     |  1
received_lsn          |  3/852DC428
received_tli          |  1
last_msg_send_time    |  2017-09-06 15:35:28.178167+08
last_msg_receipt_time |  2017-09-06 15:35:28.177706+08
latest_end_lsn        |  3/852DC508
latest_end_time       |  2017-09-0615:35:28.178167+08
slot_name             |  
conninfo              |  user=repuser passfile=/home/postgres/.pgpass dbname=replication
    host=192.168.28.74 port=1921 application_name=node2 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

以上主要字段信息如下:
pid:WAL接收进程的进程号。status: WAL接收进程的状态。
receive_start_lsn: WAL接收进程启动后使用的第一个 WAL日志位置。received_lsn:最近接收并写入WAL日志文件的WAL位置。
last_msg_send_time :备库接收到发送进程最后一个消息后，向主库发回确认消息的发送时间。
last_msg_receipt_time:备库接收到发送进程最后一个消息的接收时间。
conninfo: WAL接收进程使用的连接串，连接信息由备库SPGDATA目录的recovery.
conf配置文件的 primary_conninfo参数配置。