正如我们所知，mysql 异步进行复制。我听说我需要一些额外的插件来做
同步复制。
因此，让我们考虑异步复制的情况：master 将事件写入其二进制日志，但不知道 master2 是否或何时检索并处理了它们。使用异步复制，如果 master1 崩溃，它已提交的事务可能不会传输到任何 master2。
我的问题是这些事务是否会在 master1 再次启动时最终复制到 master2 ？如果不是，那么这是一个很大的不一致问题。
对于主从复制，我的问题是相同的，并且 master 在相同的情况下关闭。
我需要一些特殊的配置参数来让它自动发生吗？
或者我是否必须手动转储 master1 中的数据并导入 master2 等？
======
更新：我可能误用了上面的“崩溃”这个词，我只是想参考一下master1在一段时间内无法将数据同步给其他人的情况。下面的回复（感谢）涵盖了两种情况：例如由于磁盘故障导致的真正不可恢复的崩溃，或者由于网络问题而导致的暂时离线问题等。
如果 master1 在中断后重新上线，并且 binlogs 没有丢失，那么副本可以下载它错过的任何 binlogs。对于本次讨论，master2 是一个副本。
当然，如果 master1 的崩溃严重到损坏或丢失其二进制日志，那么您就不走运了。
也有 master1 将更改写入其数据库但 binlog 条目在崩溃中丢失的情况。为了解决这个风险，您可以设置sync_binlog=1master1 上的事务要求相应的 binlog 条目在磁盘上是安全的，否则事务无法完成。
但是在每次提交时将二进制日志同步到磁盘有一些开销，许多站点决定他们宁愿拥有性能而不是数据安全。确实，某些工作负载的每秒事务处理率太高，无法实现这一点。即每秒磁盘同步数有一个物理上限。然后，解决方案需要获得更快的磁盘（或 SSD），或者将工作负载分散到多个服务器上。
I've also seen a reverse situation: the binlog entry is written to the filesystem cache on the master1, and the replica downloads that binlog entry and the replica applies it, but that entry never makes it to disk on the master1 because of the disk was having intermittent failures. So ironically, the replica had processed changes that were never committed to disk on the master!
You mentioned the possibility of synchronous replication. MySQL doesn't really have this option. The closest they have is Semisynchronous Replication which means that a transaction on master1 isn't allowed to commit until at least one semi-sync replica confirms that it has received the transaction's binlog entry. This means you'll never have a discrepancy like those described above. But this adds some latency to every COMMIT.
Why is it "semi"-synchronous? Because the COMMIT on master1 doesn't have to wait for the transaction to be executed on the replica, it only has to wait for the replica to acknowledge receiving the binlog event. The replica can still lag behind.
Comment from @ceejayoz mentions Percona XtraDB Cluster. This works pretty similarly to semisynchronous replication, in that during COMMIT, the writer node must transmit the log for that transaction to all other nodes in the cluster. So the latency is the speed at which the slowest node acknowledges receiving the event.
If master1 crashes, the committed transactions will be available at the logfile, and as soon as it is up again, they'll be delivered to the slave(s), in this case, master2. If, by your configuration, there's a chance that while master1 was down master2 committed an identical primary key value, you'll have an inconsistency problem.
You may prevent this by assigning different primary keys by server — for example, one only writes odd numbers while the other even numbers. Or even a composed primary key that uses the server id.