面试题：PostgreSQL日志故障排查及高可用场景下的处理

Question

在一个高可用的PostgreSQL集群环境中，突然出现主从节点数据不一致的情况，且日志中记录了一些与流复制相关的报错。请阐述你将如何利用日志内容逐步排查故障，使集群恢复到正常的数据同步状态，并说明在排查过程中可能涉及到的配置参数调整以及对业务影响的最小化策略。

Answer 1

利用日志排查故障步骤

1. 收集与分析日志：
   • 仔细查看主节点和从节点上与流复制相关的日志，如postgresql.conf中配置的日志文件（通常为postgresql-%Y-%m-%d_%H%M%S.log）。
   • 查找与流复制错误相关的关键信息，例如FATAL、ERROR级别的日志记录。可能出现的报错如“connection to primary has been lost”表明主从连接问题，“replication slot has been dropped”可能涉及复制槽的异常。
2. 网络连接检查：
   • 日志中若提示连接相关错误，检查主从节点之间的网络连通性。使用ping命令确认节点之间的网络可达性，使用traceroute检查网络路径是否存在异常跳数或丢包。
   • 检查防火墙配置，确保PostgreSQL流复制使用的端口（通常为5432）在主从节点之间双向开放。在Linux系统中，通过iptables -L或firewall -cmd --list -all查看防火墙规则。
3. 复制槽与WAL（Write - Ahead Log）检查：
   • 查看日志中是否有关于复制槽的错误。在主节点上，使用SELECT * FROM pg_replication_slots;查看复制槽状态。若复制槽丢失或异常，可能需要重新创建。
   • 检查WAL归档和传送状态。主节点上确认WAL归档是否正常，postgresql.conf中的archive_mode是否设置为on，archive_command是否正确配置。从节点查看WAL接收情况，recovery.conf（或postgresql.auto.conf中的相关配置）中的primary_conninfo是否正确指向主节点。
4. 角色与权限检查：
   • 确认主从节点上用于流复制的角色权限是否正确。在主节点上，确保复制用户具有REPLICATION权限，例如CREATE ROLE replication_user WITH REPLICATION LOGIN CONNECTION LIMIT 10 ENCRYPTED PASSWORD 'password';
   • 从节点使用正确的复制用户连接主节点，检查recovery.conf中的primary_user配置是否正确。

可能涉及的配置参数调整

1. 网络相关：
   • listen_addresses：在postgresql.conf中，确保主节点的listen_addresses配置正确，若只监听了localhost，可能需要修改为节点的实际IP地址或*以允许从节点连接。
   • port：确保主从节点的port配置一致且未被其他进程占用。
2. 流复制相关：
   • max_wal_senders：在主节点的postgresql.conf中，若从节点较多或日志量较大，可能需要适当增加该参数值，以允许更多的WAL发送进程。
   • wal_level：确保主从节点的wal_level配置为replica或更高（如logical），以支持流复制。

业务影响最小化策略

1. 切换只读模式：在排查故障前，将从节点设置为只读模式，使用SELECT pg_read_only(true);。这样可以避免业务写入从节点导致数据不一致问题加剧。
2. 故障转移（若必要）：若主节点故障导致数据不一致，在确保数据一致性的前提下，尽快将从节点提升为主节点。可以使用pg_ctl promote命令，然后重新配置其他从节点连接到新的主节点。
3. 逐步调整与测试：对配置参数的调整应逐步进行，每次调整后进行小范围的业务测试，确保业务不受影响。例如，先调整网络相关配置，测试网络连通性和简单的数据库操作后，再调整流复制相关参数。
4. 使用热备节点：若集群中有热备节点，可将业务流量切换到热备节点，然后在不影响业务的情况下对故障节点进行排查和修复。