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

Question

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

Answer 1

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

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

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

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

更多详情，引用我的post关于这个话题。