MySQL 复制重新同步

Question

我想建立一个零维护、无需动手的 MySQL 复制方案以用于备份目的。

但根据我的经验，这些东西最终不可避免地会不同步。也许是由于开发人员滥用、意外事故或其他未知因素。但我希望定期重新同步从属服务器，以确保未注意到的复制问题不会长期得不到纠正。

有没有人有可行/经过测试的解决方案来解决这个问题？

这是我提出的解决方案；但我愿意听取任何有处理此问题经验的人提出其他可能性：

假设这就像在主服务器上执行一样简单：

mysqldump --all-databases --master-data >dbdump.sql

然后在每台从服务器上加载该 SQL 文件，并stop slave在之前和start slave之后运行。理论上，从服务器将使用更新的主服务器坐标重新建立同步，然后我们就可以开始了。

据推测，这可以作为非高峰时段的每周工作自动完成。

但有没有更好的方法来做到这一点？

Answer 1

您是否在从服务器和主服务器上都使用 innodb 引擎？避免可能破坏复制的查询? 避免主服务器和从服务器的 mysql 非正常关闭？如果是这样，根据我的经验，复制是相当可靠的。

了解从服务器如何发生故障会很有帮助 - 复制是否停止？ 如果是 - 从服务器出现什么错误？ 或者复制运行，但从服务器与主服务器不同步？

如果是第二种情况 - 你可以尝试定期运行pt-表校验和验证从服务器是否与主服务器同步。如果你发现它们不同步 - 你可以使用pt-表同步[我发现即使在非阻塞模式下也会阻塞主服务器...所以不要在繁忙的一天中运行它]。

编辑：如果数据的总大小不是很大，您可以在主服务器上运行 innodb，并且不想使用您将定期执行的 pt-table sync write 脚本来阻止主服务器。该脚本应该：

• 运行 pt-table-checksum，如果一切正常 - 退出
• 使用以下方式获取 master 的完整转储mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=1 -A
• 在从属上运行echo "stop slave"| mysql
• 重新加载转储

由于 --master-data=1，您的转储将包含change master ...to 语句。

但老实说 - 你会更好地找到问题的根源。如果这些数据有任何价值，监控是必须的。