复制可能会以各种有趣和令人兴奋的方式中断或行为不端。您需要监控三件事：
监视复制是否正在运行的是简单地通过程序检查的问题SHOW SLAVE STATUS来看，在值Slave_IO_Running和Slave_SQL_Running。两者都应该是“是”。 来自Percona Monitoring Plugins for Nagios 的pmp-check-mysql-replication-running就是为此任务编写的。
您需要确保从站没有落后于主站太远。“太远”取决于您的应用程序可以容忍的内容以及您在主服务器上保留的二进制日志数量。因为从站上的复制是单线程的，所以从站很容易落后。 SHOW SLAVE STATUS有Seconds_Behind_Master值，但不是实际滞后的可靠指标，并且经常会跳来跳去。为了准确测量复制延迟，您需要一个外部应用程序定期将时间戳插入表中。然后，您可以从从站测量该值并将其与当前时间进行比较以获得实际的复制延迟。 pt-heartbeat是一个守护进程，它将心跳插入到您服务器上的表中。然后，您可以使用该值提醒pmp-check-mysql-replication-delay以确保它在您指定的参数范围内。
有很多方法可以使主站和从站不同步，从而导致数据不同。您需要检测这些差异并定期纠正它们，因为随着时间的推移，一个小的差异可能会变成一个非常大的差异，尤其是对于基于语句的复制。这不是一项小任务，pt-table-checksum旨在计算这些差异。每周运行一次。 pmp-check-pt-table-checksum是一个 Nagios 插件，用于在从站与主站存在数据差异时发出警报。要实际修复差异，请使用pt-table-sync。
pt-table-checksum 最近已被重写并且非常易于使用。pt-table-sync 有很多选项，可能会让人感到困惑。 仔细阅读这些文档，因为如果你不小心，你真的可以把自己射中脚。这是关于这些工具的网络研讨会。
另一件事：我可以在我的复制数据库中运行一个单独的数据库，我只是为了测试目的而运行吗？
没有什么可以阻止您修改（或补充）从站上的数据，但通常我会建议不要这样做。最好的做法是让奴隶成为read_only=1。然而，现实生活往往胜过最佳实践，并且通常将奴隶用作报告服务器。我的建议是为那些使用从站进行数据修改的人提供非常明确的访问权限，并将所有附加表放在一个单独的模式中。