PlanetScale - Blog
·
Postgres的高可用性与变更数据捕获（CDC）
内容提要
Postgres的高可用性与变更数据捕获（CDC）存在脆弱性，CDC客户端轮询数据导致主节点WAL积累。Postgres 17引入逻辑复制故障转移，但从属节点插槽资格受限，可能导致故障转移时CDC流中断。相比之下，MySQL设计更灵活，支持无外部系统的故障转移。
关键要点
-
Postgres的高可用性与变更数据捕获（CDC）存在脆弱性，CDC客户端轮询数据导致主节点WAL积累。
-
Postgres 17引入逻辑复制故障转移，但从属节点插槽资格受限，可能导致故障转移时CDC流中断。
-
Postgres集群的标准HA拓扑包括一个主节点和两个配置为半同步复制的备用节点。
-
CDC客户端通过pgoutput读取逻辑复制插槽，主节点的WAL级别为逻辑。
-
逻辑复制插槽是一个持久的、本地的对象，包含两个状态：所需的最旧WAL和订阅者确认的最新位置。
-
如果CDC客户端滞后，WAL会积累，导致HA实现的脆弱性。
-
Postgres的逻辑复制故障转移要求备用节点在接收插槽元数据时至少一次推进插槽，才能成为合格的故障转移候选者。
-
在CDC安静期，备用节点上的逻辑插槽可能因位置不一致而保持临时状态，强制故障转移时可能导致CDC流中断。
-
MySQL的设计更灵活，支持无外部系统的故障转移，CDC连接器可以从任何合适的服务器恢复GTID位置。
-
Postgres的设计将插槽进度与集群协调紧密耦合，导致故障转移时的延迟或CDC流中断。
-
MySQL的二进制日志设计允许在故障转移时立即恢复，无需考虑插槽资格问题。
延伸解读
Postgres的高可用性挑战
Postgres在高可用性（HA）方面的设计存在明显的脆弱性，尤其是在变更数据捕获（CDC）场景中。由于CDC客户端的轮询机制，主节点的WAL会不断积累，这可能导致在故障转移时出现流中断的风险。用户在部署Postgres时需特别关注这一点，以避免在关键时刻影响数据流的稳定性。
与MySQL的比较
与Postgres相比，MySQL在故障转移方面的设计更为灵活。MySQL的二进制日志允许在故障转移时立即恢复，无需考虑插槽资格问题。这种设计使得MySQL在处理CDC时能够更好地应对延迟和故障，用户在选择数据库时应考虑这些差异，以满足业务的高可用性需求。
故障转移准备的关键条件
在Postgres中，备用节点的故障转移准备取决于插槽的状态、位置一致性和持久性。这意味着在进行故障转移时，必须确保备用节点的插槽已同步且未被无效化。用户在进行系统维护或升级时，应提前检查这些条件，以确保故障转移的顺利进行。
延伸问答
Postgres的高可用性和变更数据捕获（CDC）存在哪些脆弱性？
Postgres的CDC客户端轮询数据导致主节点WAL积累，且在故障转移时可能导致CDC流中断。
Postgres 17引入的逻辑复制故障转移有什么限制？
从属节点插槽资格受限，必须至少推进插槽一次才能成为合格的故障转移候选者。
Postgres的CDC客户端是如何工作的？
CDC客户端通过pgoutput读取逻辑复制插槽，主节点的WAL级别为逻辑，并每隔几小时轮询数据。
Postgres与MySQL在故障转移设计上有什么不同？
MySQL的设计更灵活，支持无外部系统的故障转移，而Postgres的设计将插槽进度与集群协调紧密耦合。
在Postgres中，CDC流中断的原因是什么？
CDC流中断可能由于备用节点的逻辑插槽在安静期保持临时状态，导致故障转移时无法正常工作。
Postgres的WAL积累会导致什么问题？
WAL积累可能导致高可用性实现的脆弱性，甚至可能导致写不可用或紧急故障转移。
