【发布时间】：2016-08-21 23:53:43
【问题描述】：
我正在 docker 容器内的单独 ubuntu EC2 实例上运行 postgres 9.5.2 主/从流式 repl 集群，其中 WAL-E 从主节点流式传输到 S3 存储桶。从站是同步的。一个同步从属设备位于今天磁盘空间不足的 EC2 实例上（该机器上运行着其他服务/docker 容器）。这导致那个奴隶停止工作，自然而然地进入了不好的状态。当我意识到它已经关闭时，主人已经删除了特定奴隶需要赶上的 wal 段。因此，我暂时关闭了运行从站的 docker 容器。我没想过要检查主人，因为奴隶倒下不应该对主人造成任何问题。但这似乎引起了某种类型的问题。这是我在日志中看到的唯一错误
WARNING: canceling the wait for synchronous replication and terminating connection due to administrator command
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
FATAL: terminating connection due to administrator command
FATAL: terminating connection due to administrator command
WAL 和复制配置。其他都是系统默认的
wal_level = hot_standby
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9
archive_mode = on
archive_command = 'envdir /etc/wal-e.d/env /usr/local/bin/wal-e wal-push %p'
archive_timeout = 60
max_wal_senders = 5
wal_keep_segments = 8
hot_standby = on
这导致主机有新的连接挂起，然后不会终止连接。在所有的连接都用完之前，他们只会感到疲倦。
有谁知道为什么当一个奴隶离开集群时，主人会进入这样的糟糕状态？这似乎不对。我认为奴隶应该对主人能够执行其工作的影响为 0。如果从服务器出现故障或从集群中掉线，主服务器不应该关心并继续做它正在做的事情。为什么会这样？
【问题讨论】：
-
你能发布你的复制设置吗
-
我已经添加了我拥有的 postgresql.conf 复制设置。
-
您正在使用第三方软件包进行存档。我只能假设这是由此引起的一些问题
-
第三方应用程序是 WAL-E，它不用于复制，仅将 wal 发送到我的 S3 存储桶。存档命令本身只是告诉 wal-e 这里是存档文件的位置，并将副本推送到 s3 存储桶。这将如何影响复制？另外，我之前已经从这个集群中删除了节点，这从未发生过。
-
因为从服务器宕机不会导致主服务器出现任何问题。但这似乎引起了某种类型的问题。好吧，您正在使用 同步 复制，因此主服务器将等待至少一个副本确认重播。清除主服务器上的
synchronous_standby_names或从中删除问题副本。
标签： postgresql database-replication master-slave postgresql-9.5