YugaByte DB的复制模型与PostgreSQL主从复制相比有什么相似或不同？
答案 0 :(得分：2)
PostgreSQL是单节点RDBMS。由于不是所有数据都是从单个节点提供的，因此表没有水平划分/分割为较小的组件。在高可用性（HA）部署中，使用主从节点对。主机负责处理对数据的写入/更新。提交的数据异步复制到完全独立的“从属”实例。当主服务器发生故障时，应用程序客户端可以开始与从属实例进行通信，但需要注意的是，他们将看不到最近在主服务器上提交但尚未复制到从属服务器上的数据。通常，主到从故障转移，主修复和从到主故障回复都是手动处理的。
另一方面，YugaByte数据库是Google Spanner-inspired分布式RDBMS，其中HA部署至少从3个节点开始。表被水平划分/分割为更小的组件，称为“平板电脑”。平板电脑平均分配到所有可用节点。通过自动在另外2个节点上存储2个额外副本，从而使每个平板电脑具有故障恢复能力，从而总共产生3个副本。这3个副本称为平板电脑组。 而不是在涉及所有数据的整体实例级别上管理复制（就像PostgreSQL一样），而是使用称为Raft的分布式共识协议在单个平板电脑组级别上管理YugaByte DB的复制。
筏式（以及称为“领导者租赁”的机制）可确保3份副本中只有1个可以成为领导者（负责提供写入/更新和强烈一致的读取）。给定行的写入操作由相应的平板电脑负责人处理，该负责人在向客户端应用程序确认成功之前在本地提交数据以及至少一个关注者。节点丢失会导致该节点上托管的平板电脑领导者丢失。在新的平板电脑负责人被自动选为其余关注者之前，无法处理这些平板电脑的新更新。这种自动选择通常需要几秒钟，并且主要取决于节点之间的网络延迟。选举完成后，即使对于受节点故障影响的平板电脑，集群也可以接受写入。
后面要加上YugaByte DB的Google Spanner设计确实要求将数据提交到比PostgreSQL多一个副本的位置，这意味着与PostgreSQL相比，写延迟增加了。但是作为回报，获得的好处是内置的修复（通过领导者自动选举）和故障转移（在选举后转移到新领导者）。即使故障回复（在故障节点重新联机之后）也是自动的。 当运行数据库集群的基础架构比以前更容易发生故障时，这种设计是更好的选择。
有关更多详细信息，请参阅我的post关于该主题。