database - YugaByte DB 的复制模型如何？

Question

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

Answer 1

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

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

Raft（以及一种称为 Leader Leases 的机制）确保 3 个副本中只有 1 个可以在任何时候成为领导者（负责提供写入/更新和强一致性读取）。给定行的写入由相应的 tablet 领导者处理，该领导者在向客户端应用程序确认成功之前在本地提交数据以及至少 1 个跟随者。节点丢失会导致该节点上托管的平板电脑领导者丢失。New updates on those tablets cannot be processed till new tablet leaders get auto-elected among the remaining followers. 这种自动选举通常需要几秒钟，主要取决于节点之间的网络延迟。选举完成后，即使对于受节点故障影响的平板电脑，集群也准备好接受写入。

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

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