|
PostgreSQL流复制环境下，在备用服务器上进行查询时，日志输出中出现以下报错： FATAL: terminating connection due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed. HINT: In a moment you should be able to reconnect to the database and repeat your command. 问题原因: 当备用服务器在WAL流中获取更新/删除，而且该更新/删除将使正在运行的查询当前正在访问的数据无效，在这种情况下将发生此类错误。 这种错误出现的主要场景是：备用服务器有长时间运行的查询来查看主服务器上具有重要活动的表。一个示例是主服务器上的管理员在备用服务器正在查询的表上运行DROP TABLE命令。显然，如果在备用数据库上应用了DROP TABLE命令，则备用服务器上的查询无法继续。当在主服务器上运行DROP TABLE命令时，主服务器并不知道备用服务器上运行了哪些查询，因此它不会等待备用服务器上的任何此类查询。当备用服务器上的查询仍在运行时，WAL的更改记录进入备用数据库，从而导致冲突。 当冲突的查询很短时，通常希望通过稍微延迟WAL应用进程来使它完成。但是WAL应用进程的长时间延迟通常是不可取的。因此，取消机制具有max_standby_archive_delay和max_standby_streaming_delay参数，它们定义WAL应用进程中允许的最大延迟。一旦超过max_standby_archive_delay或max_standby_streaming_delay指定的延迟，冲突的查询将被取消。这通常会导致取消错误。 备用服务器上的查询和WAL重放之间冲突的最常见原因是“早期清理”。通常，PostgreSQL允许在没有需要查看它们的事务时清除旧的行版本，以确保根据MVCC规则可以正确地查看数据。但是此规则只能应用于在主服务器上执行的事务。因此，主服务器上的清理可能会删除备用数据库上的事务仍然可见的行版本。 解决方案: 1）在备用数据库上设置hot_standby_feedback=on，它将传递信息给主数据库，表示仍然需要表中的特定行，这可以防止VACUUM操作删除最近的死行，因此不会发生清除冲突。它允许备用服务器上的查询能够可靠地完成，但是将导致主服务器上的膨胀现象，当备用服务器上的查询长时间不结束时，此膨胀现象尤为明显。 2）提高max_standby_archive_delay或者max_standby_streaming_delay参数，它允许备用服务器特意增加复制延迟以允许查询的完成。如果备用服务器会频繁的连接和断开连接，您可能需要进行调整以处理hot_standby_feedback未提供反馈的时间段。例如，可以考虑增加max_standby_archive_delay，因此在断开连接期间WAL归档文件中的冲突不会迅速的将查询取消。您还应该考虑增加max_standby_streaming_delay以避免重新连接后新收到的流式WAL条目的快速取消。但如果将它们的值设置的过大（例如1小时），主服务器和备用服务器的状态可能会出现不一致的情况。 通过第二种方法，将时间从默认30S改为300S，解决。 |
|
|
