我想知道复制在分布式数据库中的工作原理。如果可以通过彻底但易于理解的方式解释这将是很好的。
如果您可以在分布式事务和分布式复制之间进行比较,那也很好。
亲切的问候 我
答案 0 :(得分:10)
这是一个非常常见的问题,因此此答案基于我在博客上写的this article。
数据库服务器是企业系统的核心部分,如果发生故障,服务可用性可能会受到损害。
如果数据库服务器在单个服务器上运行,那么我们将出现单点故障。任何硬件问题(例如磁盘驱动器故障)或软件故障(例如驱动程序问题,更新故障)都将导致系统不可用。
如果只有一个数据库服务器节点,那么在适应更高的流量负载时,垂直扩展是唯一的选择。垂直扩展或纵向扩展意味着购买功能更强大的硬件,该硬件可提供更多资源(例如CPU,内存,I / O)来为传入的客户端事务提供服务。
对于特定的硬件配置,垂直扩展可以是扩展数据库系统的可行且简单的解决方案。问题是性价比不是线性的,因此在达到一定的阈值后,垂直缩放的收益就会递减。
垂直扩展的另一个问题是,为了升级服务器,需要停止数据库服务。因此,在硬件升级期间,该应用程序将不可用,这可能会影响基础业务运营。
为克服上述与拥有单个数据库服务器节点相关的问题,我们可以设置多个数据库服务器节点。节点越多,处理传入流量的资源就越多。
此外,如果数据库服务器节点已关闭,只要有备用数据库节点要连接,系统仍可以处理请求。因此,可以在不影响整体系统可用性的情况下完成给定数据库服务器节点的硬件或软件的升级。
拥有多个节点的挑战是数据一致性。如果所有节点在任何给定时间都处于同步状态,则系统为Linearizable,这是跨多个寄存器的数据一致性的最有力保证。
在所有数据库节点之间同步数据的过程称为复制,我们可以使用多种策略。
单主复制方案如下:
主要节点(也称为主节点)是接受写操作的节点,而副本节点只能处理只读事务。有了单一的事实来源,就可以避免数据冲突。
要使副本保持同步,主节点必须提供所有已提交事务完成的更改列表。
正如我在this article中所解释的,关系数据库系统具有一个重做日志,其中包含成功提交的所有数据更改。
PostgreSQL使用WAL(预写日志)记录来确保事务持久性和流复制。
由于存储引擎与MySQL服务器是分开的,因此MySQL使用单独的二进制日志进行复制。重做日志由InnoDB存储引擎生成,其目的是在MySQL服务器创建二进制日志的同时提供事务持久性,并存储逻辑日志记录,而不是由重做日志创建的物理日志。 / p>
通过应用在WAL或二进制日志条目中记录的相同更改,副本节点可以与主节点保持同步。
单主复制为只读事务提供水平可伸缩性。如果只读事务的数量增加,我们可以创建更多的副本节点来容纳传入的流量。
这就是水平缩放或向外扩展的全部内容。垂直缩放与需要购买功能更强大的硬件不同,可以使用商用硬件来实现水平缩放。
另一方面,由于只有一个主节点,因此只能扩大(垂直扩展)读写事务。
有关此主题的更多详细信息,请查看this article。
答案 1 :(得分:0)
我建议最初花时间查看关于复制的MySQL Docs。这是数据库复制的一个很好的例子。他们在这里:
http://dev.mysql.com/doc/refman/5.5/en/replication.html
对于一个问题来说,覆盖问题的整个范围似乎太多了。
如果您有一些具体问题,请随时发布。谢谢!
答案 2 :(得分:0)
Clustrix是一个分布式数据库,具有无共享体系结构,支持分布式事务和复制。有一些技术文档可用于描述data distribution,distributed evaluation model和内置fault tolerance,以及architecture的概述。
作为MySQL的替代品,Clustrix实现了MySQL的复制策略,并生成MySQL格式的binlog,这些binlog是序列化的,因此Clustrix可以充当MySQL的Master或Slave。