【DB吐槽大】第72期 - PG wal 联网协议不够发达

背景

1、产品的问题点

• PG wal 联网协议不够发达

2、问题点背后涉及的技术原理

• 一个PG 集群有主实例、通过wal流复制建立的一个或多个从实例、从实例还可以集联形成多级从库.
• 集群拓扑是有根节点的树状数据流结构.
• 从节点的需要用于replay的WAL数据可以从哪里索取呢?

• • 配置好的上游节点, 上游从pg_wal目录读出来, 发送给下游
  • 自己的pg_wal目录中查找
  • 使用restore_command获取已归档的文件, 这个命令配置在自己的节点中, 通过shell命令获取. 传入参数中最重要的是所需的wal文件名.

• 在这个集群中, 不同的节点可能部署在不同的主机上, 用于存储WAL的归档的设备, 可能只能被某些节点访问(通常归档由主节点产生, 并copy到归档设备中).

• • 对于已归档的wal文件, 并且是最近一个已完成的检查点之前的, 并且不在wal_keep_size保护范围内, 这样的wal文件可能被删除. 然而下游节点可能因为各种原因还没有及时接收到这样的WAL文件. 那下游节点怎么办? 只能使用restore_command获取已归档的文件, 但是前面说了, 可能只有主节点有归档目录的权限, 怎么办? 重建从库?
  • 核心问题是什么? 上游节点不能代替下游节点使用restore_command, 然后再将wal发送给下游节点.

3、这个问题将影响哪些行业以及业务场景

• 主从、流复制从库通用问题

4、会导致什么问题?

• 如果上游节点wal已被清楚, 而且下游节点没有权限获取归档目录中的wal文件, 那么将需要人工介入, 或者重建从库.

5、业务上应该如何避免这个坑

• 人工介入, 拷贝已清理的wal文件
• 共享wal归档, 使用restore_command从归档文件中获取已从pg_wal目录清理的wal文件.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 复杂度增加

7、数据库未来产品迭代如何修复这个坑

• 希望内核层面可以支持peer 节点之间、上游与下游之间能够通过流复制协议互相发送wal文件.
• 上游可以通过restore_command获取已清理的wal文件并发送给下游.
• 如果是集群拓扑的其他平级节点或分叉节点来发, 可以通过peer约束判定wal文件的正确性.

• • system_id 相同, 表示这是同一个集群
  • timeline + LSN 匹配, 表示这是我需要的wal内容.

• 扩展诉求: 实际上集群拓扑的监控等信息都可以更强的联动. 实现更有集群意义的dashboard, 甚至与client driver进行联动, 实现更无缝的HA, 负载均衡等.