day5

Day 5: 流复制故障排除与高可用配置 – 详细步骤

上午：流复制故障排除

在流复制的配置过程中或运行时，可能会遇到各种问题。常见的故障包括复制失败、WAL 日志同步不及时、权限问题等。下面的课程将涵盖如何诊断和解决这些问题。

1. 查看复制状态

要检查流复制是否正常运行，可以在 主服务器 上使用以下命令查看当前复制状态：

SELECT * FROM pg_stat_replication;

这条命令会显示从服务器的连接状态、WAL 发送进度等重要信息。如果没有返回结果，说明没有从服务器连接到主服务器。

2. 常见问题排查

2.1 主从服务器无法连接

• 问题表现: 从服务器无法连接主服务器，或者在主服务器上查询 pg_stat_replication 时没有显示从服务器。

• 解决步骤:

  1. 检查主服务器上的 pg_hba.conf 文件，确保从服务器的 IP 地址和复制权限已正确配置：

     host replication replicator 192.168.1.2/32 md5

  2. 确保主服务器的 postgresql.conf 文件中正确设置了 listen_addresses 和 wal_level：

     listen_addresses = '*'
     wal_level = replica

  3. 确保主从服务器之间的防火墙或网络设置允许 TCP 端口 5432 的流量。

  4. 使用 ping 和 telnet 验证从服务器能否连接到主服务器：

     ping 192.168.1.1
     telnet 192.168.1.1 5432

2.2 从服务器无法同步数据

• 问题表现: 主服务器发送的 WAL 日志没有被从服务器正确接收，可能会出现 FATAL: could not receive data from WAL stream 错误。

• 解决步骤:

  1. 检查从服务器的 postgresql.auto.conf 文件，确保 primary_conninfo 设置正确：

     primary_conninfo = 'host=192.168.1.1 port=5432 user=replicator password=replicator_password'

  2. 检查从服务器日志文件（通常在 /var/lib/pgsql/14/data/log/）中的错误信息。

  3. 在主服务器上，查看是否有足够的 WAL 日志保存：

     ls /var/lib/pgsql/14/archive/

     如果没有足够的 WAL 日志保存，增加 wal_keep_segments 或启用 WAL 归档。

2.3 主服务器负载过高或 WALS 过快产生

• 问题表现: 当主服务器负载过高，或者 WAL 产生速度比从服务器的处理能力快，可能会导致复制延迟。
• 解决步骤:
  1. 增加主服务器的 max_wal_senders 和 max_replication_slots 配置参数，以允许更多的复制连接。

     max_wal_senders = 5
     max_replication_slots = 5

  2. 优化主服务器的磁盘和网络性能，确保 WAL 发送通畅。

3. 实时监控与日志分析

1. 查看 PostgreSQL 日志：

   • 主服务器日志：

     tail -f /var/lib/pgsql/14/data/log/postgresql-<date>.log

   • 从服务器日志：

     tail -f /var/lib/pgsql/14/data/log/postgresql-<date>.log

2. 监控延迟：

   • 在主服务器上，监控复制延迟：

     SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn, sent_lsn - replay_lsn AS replication_delay
     FROM pg_stat_replication;

3. WAL 日志位置检查：
   在主服务器和从服务器上分别查看当前的 WAL 日志位置，确保它们保持同步：

   • 主服务器：

     SELECT pg_current_wal_lsn();

   • 从服务器：

     SELECT pg_last_wal_receive_lsn();

下午：高可用配置与测试步骤

为了实现 PostgreSQL 流复制的高可用性，需要配置自动故障转移机制。我们将使用 pg_ctl promote 命令实现手动故障转移，并介绍如何测试故障转移。

1. 配置手动故障转移

1. 手动提升从服务器为主服务器：
   在从服务器上，可以通过 pg_ctl promote 命令将其提升为主服务器：

   sudo -u postgres pg_ctl promote

2. 测试手动故障转移：

   • 首先，在主服务器上停止 PostgreSQL 服务：

     sudo systemctl stop postgresql-14

   • 然后，在从服务器上执行 pg_ctl promote，提升其为主服务器：

     sudo -u postgres pg_ctl promote

   • 最后，检查从服务器的 pg_stat_replication 状态，确保其已成为主服务器。

3. 主服务器恢复后重新配置为从服务器：
   当主服务器重新启动后，需要将其配置为新的从服务器：

   • 清空主服务器的数据目录：

     sudo rm -rf /var/lib/pgsql/14/data/*

   • 从新的主服务器上使用 pg_basebackup 同步数据：

     sudo -u postgres pg_basebackup -h 192.168.1.2 -D /var/lib/pgsql/14/data/ -P -U replicator --wal-method=stream

4. 恢复服务：

   • 重启主服务器并作为从服务器运行：

     sudo systemctl start postgresql-14

2. 自动故障转移工具（可选）

为了实现自动故障转移，您可以使用 Patroni 或 repmgr 等工具。以下是 repmgr 的简单配置步骤：

1. 安装 repmgr：

   sudo yum install -y repmgr14

2. 配置 repmgr.conf：
   在每台服务器上配置 repmgr.conf 文件，设置节点名称、角色等信息：

   node_id=1
   node_name='node1'
   conninfo='host=192.168.1.1 user=repmgr dbname=repmgr'

3. 初始化 repmgr：
   在主服务器上初始化 repmgr 数据库：

   sudo -u postgres repmgr -f /etc/repmgr/14/repmgr.conf primary register

4. 启动 repmgrd 服务：

   sudo systemctl start repmgrd

测试步骤

1. 手动模拟主服务器故障：

   • 关闭主服务器，观察从服务器是否能够接管流量。
   • 停止 PostgreSQL 服务：

     sudo systemctl stop postgresql-14

2. 在从服务器上进行故障转移：

   • 执行以下命令，提升从服务器为主服务器：

     sudo -u postgres pg_ctl promote

3. 验证高可用：

   • 在新主服务器上执行以下查询，确认它已成为主服务器：

     SELECT * FROM pg_stat_replication;

4. 恢复原主服务器并重新加入集群：

   • 重新配置原主服务器为从服务器，使用 pg_basebackup 同步数据并重新启动。

总结

通过配置流复制和故障排除步骤，以及进行手动或自动的故障转移，您可以确保 PostgreSQL 集群在遇到故障时能够迅速恢复高可用性。这种高可用配置可以有效地减少数据库的宕机时间，保障业务的连续性。