我已经实现了一个基于主 – 主复制的高可用性解决scheme。 在前端部分有一个机制，保证在给定的时间只有一个数据库被读/写（即我们只使用HA进行复制）。
我已经确认复制按预期工作，但我想知道故障情况和恢复。 特别是，我担心当一个主服务器在一个不可恢复的状态下失败，并且需要从另一个主服务器重新创build时，会发生什么情况：
mysqldump创build转储（我们的数据库非常大，而mysqldump在几个月的使用后可能需要几个小时）。 第一个问题的简单解决scheme是使用第三个数据库作为备份，从中我可以执行mysqldump 。 但是，如何确保重新创build的主服务器能够以一致的方式从运行的主服务器启动复制？
我知道这个问题有两个基本的解决方法。 首先，如果你运行的是InnoDB，而不是Myisam，那么你可以在一个事务中进行备份（–single-transaction –lock-tables = FALSE），结合–flush-logs（不需要但很好）和 – master-data将为您提供复制位置信息的一致备份。 刷新日志将在创build转储之前重置日志，这意味着位置始终为106，而–master-data会将日志文件名称和位置正确放入转储文件中。 当然，你必须在master上运行这个–master-data才能工作。
您提到的第二种方法是使用第三台主机来创build备份。 在这种情况下，您需要停止复制，确保数据库是read_only（虽然实际上，所有副本都应该是只读的，因为这不会影响从复制写入），然后创build备份并logging复制位置。 在这种情况下，你不能使用–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
注意：你可以并且应该从另一个副本testing这个。
附加说明：如果您有一个副本池（例如，如果您已经从Web应用程序的写入中分离读取），则副本可能与新主节点不同步; 如果故障转移发生在大量写入I / O的时间段，因为副本stream是asynchronous的，并且不能保证备用与故障转移时其他副本位于同一位置。 但是，这还没有发生在我身上呢…