YugaByte DB 的复制模型如何？

Question

YugaByte DB 的复制模型与 PostgreSQL 主从复制相比，有何相似或不同？

Answer 1

PostgreSQL 是一个单节点的 RDBMS。表不会水平分区/分片成更小的组件，因为无论如何所有数据都是从单个节点提供的。在高可用 (HA) 部署中，使用主从节点对。master 负责处理对数据的写入/更新。提交的数据被异步复制到一个完全独立的“从”实例。在主服务器发生故障时，应用程序客户端可以开始与从属实例通信，但需要注意的是，他们不会看到最近在主服务器上提交但尚未复制到从服务器的数据。通常主到从故障转移、主修复和从到主故障恢复是手动处理的。

另一方面，YugaByte DB 是受Google Spanner 启发的分布式 RDBMS，其中 HA 部署从至少 3 个节点开始。表被水平分区/分片成更小的组件，称为“平板电脑”。平板电脑平均分配到所有可用节点。通过在 2 个额外的节点上自动存储 2 个额外的副本，使每个平板电脑对故障具有弹性，总共有 3 个副本。这 3 个副本被称为一个平板电脑组。YugaByte DB 不是在涉及所有数据的整体实例级别管理复制（如 PostgreSQL 那样），而是使用称为Raft的分布式共识协议在单个平板电脑组级别管理复制。

Raft（连同一种称为Leader Leases的机制）确保在任何时候3个副本中只有1个可以成为leader（负责提供写/更新和强一致性读）。给定行的写入由相应的平板电脑领导者处理，该领导者在向客户端应用程序确认成功之前在本地提交数据以及至少 1 个追随者。节点丢失会导致该节点上托管的平板电脑领导者丢失。在剩余的追随者中自动选出新的平板电脑领导者之前，无法处理这些平板电脑上的新更新。这种自动选举通常需要几秒钟，主要取决于节点之间的网络延迟。选举完成后，集群准备好接受写入，即使是受节点故障影响的平板电脑。

YugaByte DB 遵循的 Google Spanner 设计确实需要比 PostgreSQL 多提交一份数据，这意味着与 PostgreSQL 相比增加了写入延迟。但作为回报，获得的好处是内置修复（通过领导者自动选举）和故障转移（选举后到新领导者）。即使故障恢复（在故障节点重新联机后）也是自动的。当运行数据库集群的基础设施预计会比以前更频繁地失败时，这种设计是更好的选择。

有关更多详细信息，请参阅我关于此主题的帖子。