复制如何在分布式数据库中工作

Question

我想知道复制在分布式数据库中是如何工作的。 如果能以彻底但易于理解的方式解释这一点，那就太好了。

如果您可以在分布式事务和分布式复制之间进行比较，那也很好。

Answer 1

单点故障

数据库服务器是企业系统的核心部分，如果出现故障，服务可用性可能会受到影响。

如果数据库服务器在单个服务器上运行，那么我们就会出现单点故障。 任何硬件问题（例如，磁盘驱动器故障）或软件故障（例如，驱动程序问题、故障更新）都会导致系统不可用。

有限的资源

如果只有一个数据库服务器节点，那么在适应更高的流量负载时，垂直扩展是唯一的选择。 垂直扩展或纵向扩展意味着购买功能更强大的硬件，它提供更多资源（例如 CPU、内存、I/O）来为传入的客户端事务提供服务。

对于特定的硬件配置，垂直扩展可以是扩展数据库系统的可行且简单的解决方案。 问题是性价比不是线性的，所以在某个阈值之后，你会从垂直扩展中得到递减的回报。

垂直扩展的另一个问题是，为了升级服务器，需要停止数据库服务。 因此，在硬件升级期间，应用程序将不可用，这会影响底层业务运营。

数据库复制

为了克服与拥有单个数据库服务器节点相关的上述问题，我们可以设置多个数据库服务器节点。 节点越多，我们处理传入流量所需的资源就越多。

此外，如果数据库服务器节点关闭，只要有备用数据库节点要连接，系统仍然可以处理请求。 因此，可以在不影响整体系统可用性的情况下升级给定数据库服务器节点的硬件或软件。

拥有多个节点的挑战是数据一致性。 如果所有节点在任何给定时间都是同步的，则系统是Linearizable ，这是跨多个寄存器的数据一致性的最强保证。

跨所有数据库节点同步数据的过程称为复制，我们可以使用多种策略。

单主数据库复制

单主复制方案如下所示：

主节点，也称为主节点，是接受写入的节点，而副本节点只能处理只读事务。 拥有单一的事实来源使我们能够避免数据冲突。

为了保持副本同步，主节点必须提供所有已提交事务完成的更改列表。

关系数据库系统有一个重做日志，其中包含成功提交的所有数据更改。

PostgreSQL 使用 WAL（Write-Ahead Log）记录来确保事务持久性和流式复制。

由于存储引擎与 MySQL 服务器分离，因此 MySQL 使用单独的 Binary Log 进行复制。 Redo Log 由 InnoDB 存储引擎生成，其目标是提供事务持久性，而 Binary Log 由 MySQL Server 创建，它存储逻辑日志记录，而不是由 Redo Log 创建的物理日志记录。

通过应用 WAL 或二进制日志条目中记录的相同更改，副本节点可以与主节点保持同步。

水平缩放

单主复制为只读事务提供了水平可扩展性。 如果只读事务的数量增加，我们可以创建更多的副本节点来容纳传入的流量。

这就是水平扩展或向外扩展的全部意义所在。 与垂直扩展需要购买更强大的硬件不同，水平扩展可以使用商品硬件来实现。

另一方面，读写事务只能扩展（垂直扩展），因为只有一个主节点。

Answer 2

我建议最初花时间查看 MySQL Docs on Replication。 这是数据库复制的一个很好的例子。 他们在这里：

http://dev.mysql.com/doc/refman/5.5/en/replication.html

对于一个问题来说，涵盖整个问题范围似乎太多了。

如果您有一些具体问题，请随时发布。 谢谢！

Answer 3

Clustrix 是一个分布式数据库，采用无共享架构，支持分布式事务和复制。 有一些技术文档描述了数据分布、分布式评估模型和内置容错，以及 体系结构的概述。

作为 MySQL 的替代品，Clustrix 实现了 MySQL 的复制策略，并生成 MySQL 格式的 binlog，将其序列化，以便 Clustrix 可以充当 MySQL 的 Master 或 Slave。