主-主复制的恢复策略

我已经基于master-master复制为MySQL实现了HA解决方案。前端部分有一种机制可以保证在给定的时间只能读取/写入一个数据库（即，我们仅对HA使用复制）。

我已经确认复制可以按预期进行，但是我想知道故障情况和恢复。特别是，我担心一个主机在无法恢复的状态下发生故障并需要从另一主机重新创建时会发生什么情况：

• 由于另一个主mysqldump数据库处于活动状态并且很可能已被使用，因此我无法锁定它并从中创建转储（我们的数据库相当大，mysqldump使用几个月后很容易花费数小时）。
• 即使假设我有一个转储，也至关重要的是，SHOW MASTER STATUS所显示的binlog位置必须与锁定数据库后进行的转储相对应。

解决第一个问题的简单方法是使用第三个数据库作为备份，我可以从中进行备份mysqldump。但是，如何确保重新创建的母版可以以一致的方式从正在运行的母版开始复制？

我知道有两种解决此问题的基本方法。首先，如果您运行的是InnoDB而不是Myisam，则可以在事务中进行备份（--single-transaction --lock-tables = FALSE），该操作与--flush-logs（不是必需的，但很好）结合在一起，并且--master-data将为您提供具有复制位置信息的一致备份。刷新日志将在创建转储之前重置日志，这意味着位置将始终为106，而--master-data将日志文件名和位置放在转储文件中。当然，您必须在主服务器上运行此命令，才能使--master-data正常工作。

您提到的第二种方法是使用第三台主机创建备份。在这种情况下，您需要停止复制，确保数据库是只读的（尽管实际上，所有副本都应该是只读的，因为这不会影响复制的写操作），然后创建备份并记录复制位置。在这种情况下，不能使用--master-data。相反，您可以执行以下操作：

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

如果需要从此备份中还原，则可以运行还原，然后设置复制，其中两个参数master_log_file和master_log_pos来自DB.replication文件：

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

注意：您可以并且应该从另一个副本进行测试。

附加说明：如果您有一个副本池（例如，如果您将Web应用程序的读写与读取分开），则副本可能与新的主副本不同步；如果故障转移发生在繁重的写入I / O期间，则可能会发生这种情况，因为这些副本是异步流式传输的，并且不能保证当您进行故障转移时，备用数据库与其他副本位于同一位置。但是，这还没有发生在我身上...