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

Question

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

如果你能在分布式事务和分布式复制之间做一个比较，那就更好了。

Answer 1

单点故障

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

​

​

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

有限的资源

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

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

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

数据库复制

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

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

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

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

单主数据库复制

单主复制方案如下所示：

​

​

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

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

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

PostgreSQL使用WAL (预写日志)记录来确保事务持久性和流复制。

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

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

水平缩放

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

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

另一方面，读写事务只能向上扩展(垂直扩展)，因为只有一个主节点。

Answer 2

我建议先花点时间复习一下关于复制的MySQL文档。这是一个很好的数据库复制示例。它们在这里：

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

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

如果你有一些具体的问题，请随时张贴。谢谢!

Answer 3

Clustrix是一个分布式数据库，具有支持分布式事务和复制的无共享体系结构。有一些技术文档描述了data distribution、distributed evaluation model和内置的fault tolerance，并概述了architecture。

作为MySQL的替代品，Clustrix实现了MySQL的复制策略，并生成MySQL格式的二进制日志，这些binlog被序列化，以便Clustrix可以充当MySQL的主或从。