我通常使用以下SQL查询来检查Postgres v11的状态。

在master上：

select * from pg_stat_replication;

字符串

副本上（我是流复制）：

select * from pg_stat_wal_receiver;

型

在主服务器上，pg_stat_replication提供有关正在进行的复制的数据：

select client_addr, state, sent_location, write_location,
        flush_location, replay_location from pg_stat_replication;

字符串
在postgresql v10上：

select client_addr, state, sent_lsn, write_lsn,
    flush_lsn, replay_lsn from pg_stat_replication;

型

在PostgreSQL中显示复制状态

在服务器上

postgres=# select usename,application_name,client_addr,backend_start,state,sync_state from pg_stat_replication ;

usename   | application_name |  client_addr   |         backend_start         |   state   | sync_state 
------------+------------------+----------------+-------------------------------+-----------+------------
replicator | walreceiver      | 192.168.10.132 | 2018-07-06 06:12:20.786918+03 | streaming | async
(1 row)

字符串

客户端

postgres=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t
 (1 row)

postgres=# select pg_last_xlog_receive_location();
 pg_last_xlog_receive_location 
-------------------------------
 0/540C1DB8

postgres=# select pg_last_xlog_replay_location();
 pg_last_xlog_replay_location 
------------------------------
 0/540C1DB8
 (1 row)

postgres=#    SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location()
                  THEN 0
                ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
              END AS log_delay;
 log_delay 
-----------
 0
 (1 row)

型

执行完整数据库复制时，有多个阶段：

***A）**完全备份-pg_basebackup将数据库从主服务器克隆到备用服务器（备用服务器未运行）
***B）**恢复-备用服务器启动（尚未接受连接）
***C）**WAL流-主设备和备用设备都处于一致状态并接受连接
A）完全备份

Since PostgreSQL 13您可以使用pg_stat_progress_basebackup表，在其中可以获取每个复制阶段的进度（从主复制阶段）：

psql -c "select TO_CHAR(backup_streamed::decimal/backup_total*100,'fm00D00%'),phase from pg_stat_progress_basebackup;" -t
 31.79%  | streaming database files

字符串
复制过程有多个阶段，每个阶段都报告进度：

1. initializing个
2. starting file transfer个
3. streaming database files个
4. finishing file transfer个
5. transferring WAL个
   在早期的PostgreSQL版本中，你只剩下普通的磁盘使用：

$ primary=$(du -s /var/lib/postgresql/14/main/base | awk '{print $1}')
$ replica=4648394012 # same command as above only from replica
$ echo ${replica}/${primary}*100 | bc -l
34.90793993287965597200

型
pg_stat_replication给你例如replay_lag，这对整体进度没有多大帮助。你只能估计你实际上需要保留多少WAL。

psql -c "select state, client_hostname, write_lag, replay_lag, flush_lag from pg_stat_replication;"
   state   | client_hostname |    write_lag    |   replay_lag    |    flush_lag    
-----------+-----------------+-----------------+-----------------+-----------------
 backup    |                 |                 |                 | 
 streaming |                 | 00:00:00.000516 | 12:23:15.991732 | 00:00:00.310261
(2 rows)

型

B）回收率

备用服务器已经完成了第一阶段，假设服务器能够启动（关键参数的正确配置）。现在postgres进程必须在备用服务器上重放累积的WAL或从存档中复制它们（例如使用archive_command），以达到一致的恢复状态。您可以使用pg_controldata获得LSN：

$ /usr/lib/postgresql/14/bin/pg_controldata /var/lib/postgresql/14/main | grep "Minimum recovery"
Minimum recovery ending location:     4034A/1BFFFB58

型
注意：在此阶段，主服务器上的pg_stat_replication表中没有记录。
你会在日志中注意到类似这样的内容：

FATAL:  the database system is not yet accepting connections
DETAIL:  Consistent recovery state has not been yet reached.
LOG:  restored log file "000000020004022E00000029" from archive

型
十六进制数指向一个WAL文件，可以转储（通常单行就足够了）

/usr/lib/postgresql/14/bin/pg_waldump 14/main/pg_wal/00000002000402340000003D -n 1
rmgr: Heap        len (rec/tot):     48/    48, tx: 1350166609, lsn: 40234/F4001C08, prev 40234/F3FFFDB0, desc: HEAP_CONFIRM off 52, blkref #0: rel 1663/16421/2324630632 blk 85514

型
我们正在寻找LSN部分，例如lsn: 40234/F4001C08。现在，当我们回到主服务器时，我们可以获得文件大小单位的滞后：

psql -c "SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '40234/F4001C08'));" -t
 1813 GB

型
1813 GB是当前WAL和正在重放的WAL之间的差异。
另一种选择是使用pg_controldata

$ /usr/lib/postgresql/14/bin/pg_controldata /var/lib/postgresql/14/main | grep location
Latest checkpoint's REDO location:    40335/C001D040

型
在这里，您可以获得以下LSN指针：

• Backup start location个
• Latest checkpoint's REDO location-当前恢复位置
• Minimum recovery ending location个
  C）WAL流

主服务器和备用服务器几乎处于相同的状态，两台服务器都在接受连接。除了这两台服务器之间可能存在一些延迟，这可能是由写入WAL的频率，网络传输速度等引起的。
待命状态：

psql -c "SELECT extract(epoch from now() - pg_last_xact_replay_timestamp());"

型
在主要方面：

psql -c "select state, client_hostname, write_lag, replay_lag, flush_lag from pg_stat_replication;"

型
这将给予您两个服务器之间的时间差。