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

标签 database replication distribution distributed database-replication

我想知道复制在分布式数据库中如何工作。如果能以一种全面而又易于理解的方式来解释这一点,那将是很好的。

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

最佳答案

单点故障
数据库服务器是企业系统的核心部分,如果发生故障,服务可用性可能会受到损害。
Single point of failure
如果数据库服务器在单个服务器上运行,那么我们将出现单点故障。任何硬件问题(例如,磁盘驱动器故障)或软件故障(例如,驱动程序问题,更新故障)都将导致系统不可用。
有限的资源
如果只有一个数据库服务器节点,那么在适应更高的流量负载时,垂直扩展是唯一的选择。垂直扩展或纵向扩展意味着购买功能更强大的硬件,该硬件可提供更多资源(例如CPU,内存,I/O)来为传入的客户端事务提供服务。
对于特定的硬件配置,垂直扩展可以是扩展数据库系统的可行且简单的解决方案。问题在于,性价比不是线性的,因此在达到一定的阈值之后,垂直缩放的 yield 就会递减。
垂直扩展的另一个问题是,为了升级服务器,需要停止数据库服务。因此,在硬件升级期间,该应用程序将不可用,这可能会影响基础业务运营。
数据库复制
为了克服与拥有单个数据库服务器节点相关的上述问题,我们可以设置多个数据库服务器节点。节点越多,处理传入流量的资源就越多。
此外,如果数据库服务器节点已关闭,则只要有备用数据库节点要连接,系统仍可以处理请求。因此,可以在不影响整体系统可用性的情况下完成给定数据库服务器节点的硬件或软件的升级。
具有多个节点的挑战是数据一致性。如果所有节点在任何给定时间都处于同步状态,则系统为 Linearizable ,这是跨多个寄存器的数据一致性的最有力保证。
在所有数据库节点之间同步数据的过程称为复制,我们可以使用多种策略。
单主数据库复制
单主复制方案如下所示:
Single-Primary Database Replication
主节点(也称为主节点)是接受写操作的节点,而副本节点只能处理只读事务。拥有单一的事实来源可以使我们避免数据冲突。
为了使副本保持同步,主节点必须提供所有已提交事务完成的更改列表。
关系数据库系统具有一个“重做日志”,其中包含成功提交的所有数据更改。
PostgreSQL使用WAL(预写日志)记录来确保事务持久性和流复制。
由于存储引擎与MySQL服务器是分开的,因此MySQL使用单独的二进制日志进行复制。重做日志由InnoDB存储引擎生成,其目的是在MySQL服务器创建二进制日志的同时提供事务持久性,并存储逻辑日志记录,而不是由重做日志创建的物理日志。
通过应用WAL或Binary Log条目中记录的相同更改,副本节点可以与主节点保持同步。
水平缩放
单主复制为只读事务提供水平可伸缩性。如果只读事务的数量增加,我们可以创建更多的副本节点来容纳传入的流量。
这就是水平缩放或向外扩展的全部内容。与需要购买功能更强大的硬件的垂直缩放不同,可以使用商用硬件来实现水平缩放。
另一方面,由于存在单个主节点,因此只能按比例放大(垂直缩放)读写事务。

关于database - 复制如何在分布式数据库中工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10539129/

相关文章:

mysql - 选择要从中选择数据的表名

mysql - 'fantasy football' 数据库中结果表的正确数据库结构

sql-server - 数据库复制。 2台服务器,主数据库,第二台是只读的

sql-server - 我可以在 SQL 连接字符串中使用故障转移伙伴而不进行镜像吗?

java - 高斯随机分布的 NaN 误差

c++ - C++中作为类成员的分布

matlab - 使用正常数据直方图与直接公式(matlab)的熵估计

PHP/MySQL 查询错误?

php - 更好的是,在 android 中循环读取 php 或在 php 中循环读取数据库?

java - Java 类中完整描述的 EhCache 复制不起作用