我们知道mysql是异步复制的。我听说我需要一些额外的插件来做 同步复制。
那么让我们考虑异步复制的情况： 主服务器将事件写入其二进制日志，但不知道master2是否或何时检索并处理它们。使用异步复制时，如果master1崩溃，则它已提交的事务可能尚未传输到任何master2 。
我的问题是，当master1再次启动时，这些事务最终是否会最终复制到master2？如果不是，那么这是一个很大的不一致问题。
我的问题对于主从复制是一样的，并且master在同样的情况下也是如此。
我是否需要一些特殊的配置参数才能自动生成？
或者我是否必须从master1手动转储数据并导入master2等？
==
更新： 我可能错误地使用了上面的“崩溃”这个词，我只是想提一下master1在一段时间内无法将数据同步到其他人的情况。下面的回复（谢谢）包括两种情况：例如由于磁盘故障导致的真正不可恢复的崩溃，或者由于网络问题导致的暂时脱机问题等。
答案 0 :(得分：3)
如果master1在中断后重新联机，并且binlogs没有丢失，则slave可以下载它错过的任何binlog。在本次讨论中，master2是一个奴隶。
当然，如果master1的崩溃严重到足以腐败或丢失其binlogs，那你就不走运了。
还有一些情况是master1写入了对其数据库的更改，但binlog条目在崩溃中丢失了。要解决此风险，您可以设置sync_binlog=1，以便master1上的事务要求相应的binlog条目在磁盘上是安全的，否则事务无法完成。
但是，在每个COMMIT上将binlogs同步到磁盘都会产生一些开销，许多站点认为他们宁愿拥有性能而不是数据安全性。确实，某些工作负载每秒只有太高的事务率才允许这样做。即每秒磁盘同步数的物理上限。然后，解决方案需要获得更快的磁盘（或SSD），或者将工作负载分散到多个服务器上。
我也看到了相反的情况：binlog条目被写入master1上的文件系统缓存，而slave下载了binlog条目，而slave生成了它，但是该条目从未进入master1上的磁盘，因为磁盘的间歇性故障。具有讽刺意味的是，奴隶已经处理了从未在主机上提交到磁盘的更改！
您提到了同步复制的可能性。 MySQL实际上没有这个选项。它们最接近的是Semisynchronous Replication，这意味着在至少一个半同步从站确认已收到事务的binlog条目之前，不允许master1上的事务提交。这意味着你永远不会有如上所述的差异。但这会给每个COMMIT增加一些延迟。
为什么它是“半”同步的？因为master1上的COMMIT不必等待从器件上执行事务，所以它只需要等待从器件确认接收binlog事件。奴隶仍然可以落后。
来自@ceejayoz的评论提及Percona XtraDB Cluster。这与半同步复制非常相似，因为在COMMIT期间，编写器节点必须将该事务的日志传输到集群中的所有其他节点。因此，延迟是最慢节点确认接收事件的速度。
答案 1 :(得分：1)
如果 master1 崩溃，提交的事务将在日志文件中可用，并且一旦它再次启动，它们将被传递给从属服务器，在这种情况下，<强> master2 即可。如果根据您的配置，当 master1 关闭时 master2 提交了相同的主键值，则会出现不一致问题。
您可以通过服务器分配不同的主键来防止这种情况 - 例如，一个只写奇数而另一个偶数。甚至是使用服务器ID的组合主键。