【发布时间】：2012-05-19 07:52:46
【问题描述】：
我想知道在分布式数据库中复制是如何工作的。如果能以一种透彻但易于理解的方式解释这一点，那就太好了。
如果您可以在分布式事务和分布式复制之间进行比较，那就太好了。
【问题讨论】：
标签： database replication distribution distributed database-replication
【发布时间】：2012-05-19 07:52:46
【问题描述】：
单点故障
数据库服务器是企业系统的核心部分，如果出现故障，服务可用性可能会受到影响。
如果数据库服务器在单个服务器上运行，那么我们就会遇到单点故障。任何硬件问题（例如，磁盘驱动器故障）或软件故障（例如，驱动程序问题、故障更新）都会导致系统不可用。
资源有限
如果只有一个数据库服务器节点，那么在适应更高的流量负载时，垂直扩展是唯一的选择。垂直扩展或向上扩展意味着购买更强大的硬件，从而提供更多资源（例如 CPU、内存、I/O）来服务传入的客户端事务。
在一定的硬件配置下，垂直扩展可以成为扩展数据库系统的可行且简单的解决方案。问题是性价比不是线性的，所以在达到一定阈值后，纵向扩展的收益递减。
垂直扩展的另一个问题是，为了升级服务器，需要停止数据库服务。因此，在硬件升级期间，应用程序将不可用，这可能会影响底层业务运营。
数据库复制
为了克服上述与拥有单个数据库服务器节点相关的问题，我们可以设置多个数据库服务器节点。节点越多，我们处理传入流量的资源就越多。
另外，如果一个数据库服务器节点宕机，只要有空闲的数据库节点可以连接，系统仍然可以处理请求。因此，可以在不影响整体系统可用性的情况下升级给定数据库服务器节点的硬件或软件。
拥有多个节点的挑战在于数据一致性。如果所有节点在任何给定时间都处于同步状态，则系统为Linearizable，这是跨多个寄存器的数据一致性的最强保证。
跨所有数据库节点同步数据的过程称为复制，我们可以使用多种策略。
单主数据库复制
单主复制方案如下：
主节点，也称为主节点，是接受写入的节点，而副本节点只能处理只读事务。拥有单一事实来源可以避免数据冲突。
为了保持副本同步，主节点必须提供所有已提交事务所做更改的列表。
关系数据库系统有一个重做日志，其中包含所有已成功提交的数据更改。
PostgreSQL 使用 WAL（预写日志）记录来确保事务的持久性和流式复制。
由于存储引擎与 MySQL 服务器分离，因此 MySQL 使用单独的 Binary Log 进行复制。 Redo Log 由 InnoDB 存储引擎生成，其目标是提供事务持久性，而 Binary Log 由 MySQL 服务器创建，它存储逻辑日志记录，而不是由 Redo Log 创建的物理日志。 /p>
通过应用 WAL 或二进制日志条目中记录的相同更改，副本节点可以与主节点保持同步。
水平缩放
单主复制为只读事务提供水平可扩展性。如果只读事务的数量增加，我们可以创建更多的副本节点来容纳传入的流量。
这就是水平缩放或向外扩展的意义所在。与需要购买更强大硬件的垂直扩展不同，水平扩展可以使用商品硬件来实现。
另一方面，读写事务只能扩展（垂直扩展），因为只有一个主节点。
【讨论】：
-
很好的解释@vlad！ @kneo 还有其他的复制策略，比如多领导者复制、无领导者复制等！！
Clustrix 是一个分布式数据库，具有无共享架构，支持分布式事务和复制。有一些描述data distribution、distributed evaluation model和内置fault tolerance的技术文档，以及architecture的概述。
作为 MySQL 的替代品，Clustrix 实现了 MySQL 的复制策略并生成 MySQL 格式的 binlog，这些 binlog 被序列化，以便 Clustrix 可以充当 MySQL 的 Master 或 Slave。
【讨论】：
我建议最初花时间查看 MySQL Docs on Replication。这是数据库复制的一个很好的例子。他们在这里：
http://dev.mysql.com/doc/refman/5.5/en/replication.html
一个问题似乎涵盖了您问题的整个范围。
如果您有一些具体问题，请随时发布。谢谢！
【讨论】：