如何防止只读副本在高复制延迟期间重新启动

Question

我们正在运行一个 Aurora PostgreSQL 集群，其中包含一个只读副本和主节点。

定期出现非常重的写入负载，导致较高的复制延迟。这可能会导致只读副本重新启动，这对于高可用性环境中的我们来说是不希望的。发生这种情况时，通过只读端点连接到集群的客户端会收到此 JDBC 错误：org.postgresql.util.PSQLException: FATAL: the database system is starting up。此外，AWS 控制台在日志中显示了这些内容：

只读副本已经落后于主数据库太多了。重新启动 postgres。

其次是

数据库实例已重新启动

我们可以容忍只读副本落后几分钟，但不能容忍只读副本重新启动才能赶上。

有没有办法防止只读副本在这些时间段内重新启动？

或者，是否有任何建议的调整可以减少写入负载较重期间的复制延迟？

Answer 1

我认为这就是他们所说的“按设计工作”。Aurora MySQL的文档中对此进行了说明（重点是我的）：

\n

\n

拥有多个 Aurora 副本的代价是，当底层数据库实例重新启动时，副本会在短时间内变得不可用。这些重新启动可能会在维护操作期间发生，或者当副本开始远远落后于主服务器时发生。重新启动副本会中断与相应数据库实例的现有连接。

\n

\n

我预计 Aurora PostgreSQL 也是如此，因为复制实现即使不相同，也可能非常相似。

\n

我认为这种行为的原因可以通过更改从写入实例传播到只读副本的方式来解释：发送重做记录，并且副本应以正确的顺序将它们应用到适当的本地缓存页面 - - 请参阅本演示文稿的幻灯片 27 ，这是下图的来源。

\n

\n

虽然缓存更新处理应该很快，但它仍然可能使副本不堪重负，特别是当它运行在能力较差的 AWS 实例上时。一旦副本失去了对哪些缓存页已过时、哪些未过时的跟踪，它除了从头开始之外别无选择。我认为最初的解决方案设计者选择使用现有的实例启动过程，而不是开发单独的缓存失效和重新加载机制，特别是考虑到重新启动可能相对较快。

\n

换句话说，是否有办法阻止只读副本重新启动的答案似乎是否定的。

\n

至于是否有任何建议的调整来减少复制延迟，因为延迟完全取决于副本的 CPU 和内存容量（因为不涉及 I/O），请尝试永久地或至少在这些繁重的期间扩展副本更新。

\n

如果您可以控制客户端应用程序代码，则可以修改它以更优雅地处理断开的连接，并在需要时重试。如果不这样做，您可以尝试在客户端和只读副本之间设置代理（例如 pgpool），它可以通过主动测试和重新建立连接来在一定程度上减轻痛苦。

\n

如果您觉得这些建议都不可行，您还可以联系 AWS 支持人员，看看他们是否有更好的想法。

\n