mysql master-master数据复制一致性

我们知道mysql会异步复制.我听说我需要一些额外的插件
同步复制.

因此,让我们考虑一下异步复制的情况：
主节点将事件写入其二进制日志,但不知道是否master2已经或何时检索并处理了它们.对于异步复制,如果master1崩溃,则它提交的事务可能不会传输到任何master2.

我的问题是,当master1重新启动时,这些事务是否最终会被复制到master2？如果不是,那么这是一个很大的不一致问题.

对于主从复制,我的问题是相同的,而主服务器在相同情况下宕机.

我是否需要一些特殊的配置参数才能使其自动发生？

还是我必须手动从master1中转储数据并导入到master2等中？

======

更新：
我可能在上面误用了“崩溃”一词,我只想参考master1在一段时间内未能将数据同步到其他人的情况.下面的回复(感谢)涉及两种情况：例如由于磁盘故障而导致的真正不可恢复的崩溃,或者由于网络问题而导致的临时脱机问题.

解决方法:

如果master1在中断后重新联机,并且binlog尚未丢失,则slave可以下载错过的任何binlog.对于此讨论,master2是从属.

当然,如果master1的崩溃严重到足以破坏或丢失其binlog的程度,那么您就不走运了.

在某些情况下,master1对其数据库进行了更改,但binlog条目在崩溃中丢失了.要解决此风险,您可以设置sync_binlog=1,以便master1上的事务要求相应的binlog条目在磁盘上安全,否则事务无法完成.

但是将binlog同步到每个COMMIT上的磁盘上会产生一些开销,并且许多站点决定他们宁愿具有性能而不是数据安全性.确实,某些工作负载每秒的事务处理速度太高而无法实现这一点.即每秒磁盘同步数有一个物理上限.然后,解决方案将需要获得更快的磁盘(或SSD),或将工作负载分散到多个服务器上.

我也看到了相反的情况：binlog条目被写入master1的文件系统缓存中,从服务器下载该binlog条目,而slave应用它,但是由于磁盘的存在,该条目永远不会进入到master1的磁盘上间歇性故障.具有讽刺意味的是,从服务器已经处理了从未提交给主机磁盘的更改！

您提到了同步复制的可能性. MySQL确实没有此选项.它们之间最接近的是Semisynchronous Replication,这意味着在至少一个半同步从属确认接收到该事务的binlog条目之前,不允许提交master1上的事务.这意味着您将永远不会出现上述差异.但这会增加每个COMMIT的延迟.

为什么它是“半”同步的？因为master1上的COMMIT不必等待在从属服务器上执行事务,所以它只需要等待从属服务器确认接收到binlog事件即可.奴隶仍然可以落后.

@ceejayoz的注释提到了Percona XtraDB Cluster.这与半同步复制非常相似,因为在COMMIT期间,writer节点必须将该事务的日志传输到集群中的所有其他节点.因此,延迟是最慢的节点确认接收事件的速度.

标签：database-replication,transactional-replication,mysql,database
来源： https://codeday.me/bug/20191030/1964223.html