【发布时间】：2020-02-03 23:50:23
【问题描述】：
我正在尝试在 kubernetes 上部署一个自动化的高可用 PostgreSQL 集群。在 master 故障转移或 master 临时故障的情况下，standby 会丢失流复制连接，并且在重试时，它需要很长时间才能失败并重试。
我使用 PostgreSQL 10 和流式复制（cluster-main-cluster-master-service 是一个始终路由到主服务器的服务，所有副本都连接到该服务进行复制）。我尝试在recovery.conf 的primary_conninfo 中设置connect_timeout 和keepalive 等配置，在待机postgresql.conf 中设置wal_receiver_timeout，但我无法使用它们取得任何进展。
首先，当 master 宕机时，复制停止并出现以下错误（状态 1）：
2019-10-06 14:14:54.042 +0330 [3039] LOG: replication terminated by primary server
2019-10-06 14:14:54.042 +0330 [3039] DETAIL: End of WAL reached on timeline 17 at 0/33000098.
2019-10-06 14:14:54.042 +0330 [3039] FATAL: could not send end-of-streaming message to primary: no COPY in progress
2019-10-06 14:14:55.534 +0330 [12] LOG: record with incorrect prev-link 0/2D000028 at 0/33000098
在调查 Postgres 活动后，我发现 WalReceiver 进程卡在 LibPQWalReceiverConnectwait_event（状态 2），但超时比我配置的要长得多（虽然我将 connect_timeout 设置为 10 秒，但大约需要 2 分钟）。然后，它失败并出现以下错误（状态 3）：
2019-10-06 14:17:06.035 +0330 [3264] FATAL: could not connect to the primary server: could not connect to server: Connection timed out
Is the server running on host "cluster-main-cluster-master-service" (192.168.0.166) and accepting
TCP/IP connections on port 5432?
在下一次尝试中，它成功连接了主节点（状态 4）：
2019-10-06 14:17:07.892 +0330 [5786] LOG: started streaming WAL from primary at 0/33000000 on timeline 17
我还尝试在发生卡住事件时终止进程（状态 2），当我这样做时，它会再次启动进程并连接然后正常流式传输（跳转到状态 4）。
查看netstat后，我还发现在walreceiver进程中（在故障转移情况下）与旧master有SYN_SENT状态的连接。
【问题讨论】：
标签： postgresql kubernetes tcp