热备用待办事项

来自 PostgreSQL wiki
跳转到导航跳转到搜索

也请参考这里： 热备用

待办事项

必须修复的问题

所有这些项目将在 Beta 版之前处理

  1. 截至 2010 年 2 月 13 日，没有剩余问题

严重问题

  1. 改进冲突解决或冲突避免
    • 在重放 B 树删除时，我们目前等待/取消所有正在运行的（只读）事务。 我们采取了极其保守的立场，因为我们不知道正在删除的元组有多新。 如果我们可以在 WAL 记录中存储一个更好的 latestRemovedXid 估计值，我们可以让它不那么保守。
    • Simon 说：获得更好的估计值只有在主服务器上的 xmin 水平比备用服务器更长的情况下才有用
    • 添加了一个新的过滤器，它基于 latestCompleteXid 的使用 - 在某种程度上减少了问题
    • 在黑客网站上设计和讨论了新的延迟冲突解决模型
  2. 闲置系统上的备用延迟
    • “备用延迟”被测量为当前时间戳 - 最后重放的提交记录的时间戳。 如果主服务器的活动很少，这会导致令人惊讶的结果。 例如，假设 max_standby_delay 设置为 8 小时。 备用服务器与主服务器完全同步，并且主服务器没有写入活动。 10 小时后，在备用服务器中启动了一个长时间运行的报告查询。 10 分钟后，在主服务器中执行了一个与报告查询冲突的小型事务。 我预计报告查询将在冲突事务开始 8 小时后被取消，但实际上它立即被取消了，因为自最后提交记录被重放以来已经超过 8 小时了。
    • Simon 说...更改以允许检查点更新 recoveryLastXTime（Simon 已完成）
    • Heikki：当主服务器完全闲置时，我们跳过检查点，因此在这种情况下我们仍然存在同样的问题
    • 需要将带有时间戳的保持活动添加到同步复制功能中
  3. 闲置会话问题上的语句取消
    • 当一个处于事务中的闲置事务因与恢复冲突而被杀死时，我们使用 FATAL 并杀死整个连接。 应该找到一种方法只取消当前事务。
    • Simon 说：Joachim 现在已经解决了这个问题，只需要重做和提交，Tom 发现了一些需要进一步处理的问题
  4. 性能
    • 分析
    • 看看我们是否需要有一个选项来在恢复结束时取消查询。 如果我们这样做，我们就不需要在运行时不断检查我们是否仍在恢复，因此这可能会给我们带来一些性能和可扩展性。

其他

  • 文档
  • 从 vacuum_defer_cleanup_age 添加到 max_standby_delay 的引用
  • 修复从 vacuum_defer_cleanup_age 到热备用章节的交叉引用
  • 从备用模式切换到正常运行时，我们会暂时持有准备好的事务持有的所有 AccessExclusiveLocks 两次，需要两倍的锁空间。 你可能会在此时耗尽锁空间，导致故障转移失败。 Simon：显着减少了问题。
  • 我们之前讨论过对 B 树 vacuum 记录的重放进行优化：重放必须触摸所有叶子页，因为堆扫描之间存在互锁，以确保我们不会 vacuum 掉并发索引扫描即将访问的堆元组。 在重放期间，我们不必实际读入和固定所有页，而只是检查不需要任何其他工作的页目前是否未在缓冲区缓存中固定。
    • Simon 说...保存以进行提交后优化。
  • ResolveRecoveryConflictWithVirtualXIDs 循环轮询直到受害者事务结束。 休眠会好得多。 我们需要一个带有超时的 LockAcquire 版本。 嗯，据我所知，有人最近提交了一个关于锁超时的补丁。 也许我们可以借用其中的代码？
  • 除了一个调用者之外，所有 ResolveRecoveryConflictWithVirtualXIDs 的调用者都从 GetConflictingVirtualXIDs() 获取 XID 列表。 如何提供一个简写函数来一步完成这两个步骤？ 会使调用站点不太冗长。
  • 已请求从关闭检查点启动恢复连接。 如果在主服务器启动时禁用 recovery_connections，然后恢复继续，这会导致问题，因此尚未添加。
  • 主服务器->备用服务器 NOTIFY - 使用一个特殊的可记录的 NOTIFY 命令来启用备用服务器上的 LISTEN 以接收这些事件
  • 如果我们使用 SIGUSR1 多路复用，可能会引入一个竞争条件，这会导致错误的正信号，从而导致错误的取消。 这种情况可能发生在被标识为冲突目标的实际后端在被标识后快速退出，然后一个重用相同后端槽位 *并且* 具有相同 pid 的新后端可能会被误认为是旧后端。

已解决的问题

这些问题已通过 CVS 提交得到解决

  1. Relcache 初始化文件失效
  2. 闲置会话问题上的语句取消
    • Jurka 说：不应该给出 ERROR 消息（仅此部分）
  3. 删除数据库不会取消完全闲置的备用会话
  4. 闲置会话问题上的语句取消
    • Tom 说：语句取消信号应该使用 SIGUSR1 多路复用
  5. 启动进程在一些长时间运行的进程后面等待
    • 在某些情况下，无休止的等待会导致与 LockBufferForCleanup() 死锁
    • http://archives.postgresql.org/message-id/1260959586.634.959.camel@ebony
    • 针对死锁应用了变通方法，但需要更精确地定位潜在的死锁 - 修复设计完成，现在需要仅在 max_standby_delay = -1 时应用
    • 最佳解决方案似乎是解决锁等待，然后死锁就不再是问题，因此在启动进程中添加 SIGALRM 处理。 通过指示所有后端在它们持有恢复所需的缓冲区固定时发出 ERROR 来解决问题。
  6. 通过恢复期间访问的堆页重建 B 树删除记录的 latestRemovedXid
  7. 已请求从关闭检查点启动恢复连接。
取自 "https://wiki.postgresql.ac.cn/index.php?title=Hot_Standby_TODO&oldid=17178"