PostgreSQL的视图pg_stat_replication

PostgreSQL的视图pg_stat_replication

pg_stat_replication 是 PostgreSQL 提供的一个系统视图,用于显示主服务器上当前正在进行的复制会话的信息。它可以帮助数据库管理员监控和管理主从复制的状态,确保数据的正确同步和高可靠性。

pg_stat_replication 视图字段说明

以下是 pg_stat_replication 视图中的一些主要字段及其说明:

  • pid:复制相关的后台进程的进程 ID。
  • usesysid:发起该复制会话的用户的 oid。
  • usename:发起该复制会话的用户名称。
  • application_name:复制客户端在启动时设置的应用名称。
  • client_addr:客户端的IP地址。如果连接是通过 Unix 域套接字创建的,则为空。
  • client_hostname:客户端的主机名,如果连接没有主机名解析则为空。
  • client_port:客户端的端口号。如果连接是通过 Unix 域套接字创建的,则为-1。
  • backend_start:后台进程启动的时间。
  • backend_xmin:发送者的最早未提交事务的 ID。
  • state:连接的状态(可能的值包括 ‘startup’, ‘catchup’, ‘streaming’, ‘backup’, ‘killed’)。
  • sent_lsn:主服务器最新传递给副本的 WAL 位置(Log Sequence Number)。
  • write_lsn:副本确认已经写入的最后一个 WAL 的位置。
  • flush_lsn:副本确认已经持久化到存储的最后一个 WAL 的位置(即已经同步到磁盘)。
  • replay_lsn:副本确认已经应用的最后一个 WAL 的位置。
  • write_lag:副本写入祭即延迟。
  • flush_lag:副本持久化即延迟。
  • replay_lag:副本应用即延迟。
  • sync_priority:同步优先级。如果多个副本存在满足同步优先级最低的同步副本将被选为同步副本。
  • sync_state:副本的同步状态(可能的值包括 ‘async’, ‘sync’, ‘potential’)。

使用示例

查看当前复制会话

查询并查看当前正在进行的所有复制会话:

SELECT * FROM pg_stat_replication;
查看特定复制会话的详细信息

可以根据特定字段(如 application_nameclient_addr)过滤查询:

SELECT * FROM pg_stat_replication WHERE application_name = 'replica_1';
查看复制延迟

评估主从复制的延迟情况,可以关注 write_lag, flush_lagreplay_lag 这几个字段:

SELECT 
    application_name,
    client_addr,
    write_lag,
    flush_lag,
    replay_lag
FROM 
    pg_stat_replication;
查看同步优先级和状态

分析同步复制设置中每个副本的优先级和状态:

SELECT 
    application_name,
    sync_priority,
    sync_state
FROM 
    pg_stat_replication
ORDER BY 
    sync_priority DESC;

延迟分析的示例

通过分析 pg_stat_replication 中的延迟字段,可以识别和优化复制延迟的问题:

SELECT 
    application_name,
    client_addr,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag
FROM 
    pg_stat_replication
ORDER BY 
    replay_lag DESC;

小结

使用 pg_stat_replication 视图,数据库管理员可以实时监控 PostgreSQL 主从复制的状态和性能。通过分析复制状态、延迟和同步优先级等信息,可以确保复制系统的高效运行,并及时处理可能的复制延迟和故障。合理利用这些信息,可以提升系统的可靠性和数据一致性。

<think>好的,我现在需要帮助用户解决他们遇到的PostgreSQL复制问题。用户运行了`sudo -u postgres /usr/pgsql-15/bin/repmgr service status`命令,结果显示了两个警告:node2和node3在pg_stat_replication中未找到,同时集群状态显示备节点没有正确连接到主节点。此外,repmgrd没有运行,这可能影响了监控和故障转移功能。 首先,我需要理解这些警告和状态的具体含义。`pg_stat_replication`是PostgreSQL的一个系统视图,用于显示当前活动的复制连接。如果主节点(node1)的这个视图中没有node2和node3,说明主节点没有检测到这两个备节点的复制连接。这可能意味着复制链路中断或配置错误。 接下来,用户提供的状态表中,node2和node3的Upstream列显示为“! node1”,这通常表示备节点配置中的上游节点(主节点)无法连接或存在通信问题。此外,repmgrd服务未运行,这会影响集群的自动故障转移和监控功能,可能导致问题未被及时发现。 现在需要分步骤排查可能的原因。首先,确认备节点的PostgreSQL服务是否正常运行,并且处于恢复模式。通过检查服务状态和运行`pg_is_in_recovery()`函数可以验证这一点。如果服务未启动或未正确配置,备节点无法连接到主节点。 然后,检查主节点上的复制连接。运行`SELECT * FROM pg_stat_replication;`查看是否有活跃的复制连接。如果没有,说明复制链路未建立,需要进一步排查网络和端口连通性。使用nc命令测试主节点的5432端口是否可达,以及psql连接测试,确保备节点能够成功连接到主节点。 网络问题解决后,需要检查主节点的pg_hba.conf文件,确保允许来自备节点的复制连接。正确的配置条目是必要的,否则备节点会被拒绝连接。此外,备节点的primary_conninfo参数必须正确指向主节点,包括正确的主机名、端口、用户名和密码。如果配置错误,备节点无法建立复制连接。 另一个可能的问题是复制槽的缺失。如果使用了复制槽,需要确保主节点上存在相应的复制槽,并且备节点在配置中指定了正确的`primary_slot_name`。复制槽的缺失可能导致WAL日志被过早删除,从而中断复制。 此外,用户的状态显示repmgrd未运行。repmgrd是负责监控和自动故障转移的守护进程,需要启动该服务以维持集群的健康状态。用户需要检查repmgrd的配置和日志,确保其正确运行。 如果以上步骤都确认无误,可能需要强制重新注册备节点,使用`repmgr standby follow --force`命令来重新建立复制链路。这可以解决元数据不一致的问题。 最后,用户需要验证修复后的集群状态,运行`repmgr cluster show`和检查pg_stat_replication视图,确保所有节点正常运行且复制连接已建立。同时,启动repmgrd服务以确保后续的监控和故障转移功能正常。 总结来说,用户的问题主要集中在复制链路的中断,可能由网络问题、配置错误或服务未运行引起。需要逐步排查每个环节,确认各节点的状态和配置,最终恢复复制连接并确保集群的稳定性。</think>--- 当执行 `sudo -u postgres /usr/pgsql-15/bin/repmgr service status` 后出现以下警告和状态信息时: ``` WARNING: node "node2" not found in "pg_stat_replication" WARNING: node "node3" not found in "pg_stat_replication" ``` 以及集群状态表显示备节点未正确连接到主节点: ``` ID | Name | Role | Status | Upstream | repmgrd | PID | Paused? | Upstream last seen ----+-------+---------+-----------+----------+-------------+-----+---------+-------------------- 1 | node1 | primary | * running | | not running | n/a | n/a | n/a 2 | node2 | standby | running | ! node1 | not running | n/a | n/a | n/a 3 | node3 | standby | running | ! node1 | not running | n/a | n/a | n/a ``` 这表示 **主节点(node1)未检测到 node2 和 node3 的复制连接**,且 `repmgrd` 守护进程未运行(可能影响自动故障转移)。以下是关键问题和修复步骤: --- ### **核心问题分析** 1. **复制链路中断** - 主节点的 `pg_stat_replication` 无备节点信息,说明复制连接未建立。 - 状态表中 `Upstream` 列的 `! node1` 表示备节点与主节点通信异常。 2. **`repmgrd` 未运行** - `repmgrd` 是负责监控节点状态和自动故障转移的守护进程,未运行会导致集群管理功能失效。 --- ### **分步解决方案** #### **1. 启动 `repmgrd` 服务** - **目标**:恢复集群监控和自动故障转移能力。 - **操作**: ```bash # 在所有节点执行 sudo systemctl start repmgr15 # 根据实际版本调整服务名(如 repmgr12、repmgr14) ``` - **验证**: ```bash repmgr service status ``` 检查 `repmgrd` 列是否显示为 `running`。 --- #### **2. 修复备节点复制连接** - **原因**:备节点无法连接到主节点,可能是网络、认证或配置错误。 - **操作步骤**: 1. **检查备节点日志**: ```bash # 在 node2 和 node3 上执行 tail -n 100 $PGDATA/log/postgresql.log | grep -E "FATAL|ERROR" ``` 关注以下错误: - `could not connect to server`: 网络或端口不通。 - `password authentication failed`: 认证失败。 - `invalid primary_conninfo`: 配置错误。 2. **验证主节点连接**(从备节点发起): ```bash # 在 node2 或 node3 上执行 psql "host=node1 port=5432 user=repmgr dbname=repmgr" -c "SELECT 1;" ``` - 若连接失败,检查主节点 `postgresql.conf` 的 `listen_addresses` 和防火墙规则。 3. **修正 `primary_conninfo`**: - 在备节点的 `postgresql.auto.conf` 中检查以下配置: ```ini primary_conninfo = 'host=node1 port=5432 user=repmgr password=xxx ...' ``` - 确保密码正确,且与主节点 `pg_hba.conf` 中配置的认证方式匹配。 4. **强制重建复制链路**: ```bash # 在备节点执行(以 node2 为例) repmgr standby follow -f /etc/repmgr.conf --force ``` --- #### **3. 检查主节点 `pg_hba.conf`** - **关键配置**:确保主节点允许备节点以 `repmgr` 用户连接。 - **示例条目**: ```ini # 允许 node2 和 node3 通过复制用户连接 host replication repmgr node2/32 scram-sha-256 host replication repmgr node3/32 scram-sha-256 ``` - **重载配置**: ```bash pg_ctl reload -D $PGDATA ``` --- #### **4. 验证复制槽(如使用)** - **操作**: ```sql -- 在主节点执行 SELECT slot_name, active FROM pg_replication_slots; ``` - 若复制槽未激活,需在备节点配置中添加 `primary_slot_name`: ```ini primary_conninfo = '... primary_slot_name=repmgr_slot_2 ...' ``` --- #### **5. 最终状态验证** 1. **检查集群状态**: ```bash repmgr cluster show ``` - 预期输出:所有节点 `Status` 为 `running`,`Upstream` 无 `!` 符号。 2. **检查主节点复制连接**: ```sql psql -h node1 -c "SELECT application_name, state FROM pg_stat_replication;" ``` - 应显示 `node2` 和 `node3` 的复制连接状态为 `streaming`。 --- ### **常见错误处理** | 问题现象 | 解决方案 | |------------------------------|--------------------------------------------------------------------------| | `psql: error: connection refused` | 检查主节点 `listen_addresses` 和防火墙(确保 `5432` 端口开放)。 | | `FATAL: no pg_hba.conf entry` | 在主节点 `pg_hba.conf` 添加备节点的复制权限条目。 | | `repmgr: ERROR: replication slot "xxx" does not exist` | 在主节点手动创建复制槽:`SELECT pg_create_physical_replication_slot('xxx');` | --- ### **总结** 通过以上步骤,可以修复备节点与主节点的复制链路,并恢复 `repmgrd` 的监控功能。若问题持续,需结合主备节点的 PostgreSQL 日志(`$PGDATA/log/postgresql.log`)和 `repmgr` 日志(`/var/log/repmgr/repmgr.log`)进一步排查网络、配置或权限问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值