mysql master-master数据复制一致性

Question

正如我们所知，mysql会异步执行复制。我听说我需要一些额外的插件来做
同步复制。

因此，让我们考虑异步复制的情况： 主站将事件写入其二进制日志，但不知道master2是否或何时检索并处理它们。使用异步复制，如果master1崩溃，则，它提交的事务可能未传输到任何master2。

我的问题是这些事务最终是否会在master1重新启动后最终复制到master2？如果不是，那么这是一个很大的不一致问题。

我的问题对于主从复制是一样的，主控关闭的情况相同。

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

或者我是否必须手动从master1转出数据并导入到master2等？

======

更新： 我可能误用了“崩溃”上面，我只想引用该master1未能同步的数据给他人一些时间的情况。下面的回复（谢谢）涵盖了两种情况：由于磁盘故障导致的实际不可恢复崩溃，或者由于网络问题等造成暂时脱机问题。

Answer 1

如果master1在中断后重新联机，并且binlogs天堂不会丢失，那么奴隶可以下载它遗漏的任何二进制日志。对于这个讨论，master2是一个奴隶。

当然，如果master1的崩溃足够严重，可能会损坏或丢失binlog，那么您运气不好。

还有一些情况，其中master1向其数据库写入更改，但binlog条目在崩溃中丢失。要解决此风险，您可以设置sync_binlog=1，以便master1上的事务要求相应的binlog条目在磁盘上安全，否则事务无法完成。

但是，在每个COMMIT中将binlogs同步到磁盘有一些开销，并且许多网站决定他们宁愿有比数据安全的性能。确实，有些工作负载每秒钟的事务处理速度太高，无法实现这一点。即每秒磁盘同步的数量有一个物理上限。那么解决方案需要获得更快的磁盘（或SSD），或将工作负载分散到多个服务器上。

我也看到了一种相反的情况：binlog条目被写入到master1上的文件系统缓存中，并且从属服务器下载该binlog条目并且从服务器应用它，但该条目永远不会将其记录到master1上的磁盘上因为磁盘有间歇性故障。如此具有讽刺意味的是，奴隶已经处理了从未被委托给主人磁盘的变更！

您提到了同步复制的可能性。 MySQL并不是真的有这个选项。它们最接近的是Semisynchronous Replication，这意味着master1上的事务不允许提交，直到至少有一个半同步从服务器确认它已收到事务的binlog条目。这意味着你永远不会有像上面描述的差异。但是这会给每个COMMIT增加一些延迟。

为什么它是“半” - 同步？由于master1上的COMMIT不必等待事务在从站上执行，它只需等待从站确认接收到binlog事件。奴隶仍然可以落后。

评论来自@ceejayoz提及Percona XtraDB Cluster。这与半同步复制非常类似，因为在COMMIT期间，writer节点必须将该事务的日志传输到集群中的其他节点的所有。所以延迟是最慢的节点确认接收事件的速度。

Answer 2

如果master1崩溃，提交的事务将可在日志文件，并尽快再次到了，他们将被输送到从（S），在这种情况下，master2。如果通过您的配置，有可能master1出现故障master2提交了相同的主键值，您将会遇到不一致问题。

您可以通过服务器分配不同的主键来防止这种情况 - 例如，一个只写奇数而另一个偶数。甚至是使用服务器ID的组合主键。