mysql master-master 数据复制一致性

Question

众所周知，mysql 是异步复制的。我听说我需要一些额外的插件来做
同步复制。

那么让我们考虑一下异步复制的情况:master 将事件写入其二进制日志，但不知道 master2 是否或何时检索并处理了它们。对于异步复制，如果 master1 崩溃，它提交的事务可能不会传输到任何 master2。

我的问题是，当master1再次启动时，这些事务是否最终会复制到master2？如果不是，那就是一个很大的不一致问题。

我的问题与主从复制相同，主服务器因相同情况而宕机。

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

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

======

更新:我可能用错了上面的“崩溃”这个词，我只想说master1在一段时间内无法同步数据给其他人的情况。下面的回复(感谢)包括两种情况:例如由于磁盘故障导致的真正无法恢复的崩溃，或者由于网络问题等导致的暂时离线问题。

Answer 1

如果 master1 在中断后重新上线，并且 binlog 没有丢失，那么副本可以下载它错过的任何 binlog。对于此讨论，master2 是副本。

当然，如果 master1 的崩溃严重到损坏或丢失其二进制日志，那你就倒霉了。

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

但是在每次 COMMIT 时将 binlog 同步到磁盘会产生一些开销，并且许多站点决定他们宁愿拥有性能而不是数据安全。的确，某些工作负载每秒的事务处理率太高而不允许这样做。 IE。每秒磁盘同步数有一个物理上限。然后，解决方案需要获得更快的磁盘(或 SSD)，或将工作负载分散到多台服务器上。

我也见过相反的情况:binlog 条目被写入 master1 上的文件系统缓存，副本下载该 binlog 条目并应用它，但该条目永远不会进入 master1 上的磁盘，因为磁盘有间歇性故障。具有讽刺意味的是，副本处理了从未提交到主磁盘上的磁盘的更改!

您提到了同步复制的可能性。 MySQL 并没有这个选项。他们最接近的是Semisynchronous Replication这意味着在至少一个半同步副本确认它已收到事务的二进制日志条目之前，master1 上的事务不允许提交。这意味着您永远不会出现上述差异。但这会为每个 COMMIT 增加一些延迟。

为什么是“半”同步？因为 master1 上的 COMMIT 不需要等待 replica 上的事务执行完毕，它只需要等待 replica 确认收到 binlog event。副本仍然可以落后。

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