mysql - MySQL主从复制的可靠性

Question

我有一个应用程序需要大约 30 个表的主目录，这些表需要复制到应用程序的许多(100 多个)从属副本。从站可能在他们自己的数据库实例中，或者在单个数据库实例中可能有多个从站。对主目录的任何更改都需要在合理的时间内(大约 5 分钟)复制到从属目录。我们的基础设施全部是 AWS EC2，我们使用 MySQL。主节点和从节点都将驻留在一个 AWS 区域内。

我曾计划使用主从复制，但我看到有关 MySQL 复制有时不可靠的报告，我不确定这是由于特定实现中固有的故障还是 MySQL 本身的故障。我们需要一个高度自动化和可靠的系统，可能我们必须开发监控脚本，让从服务器持续监控其相对于主服务器的目录。

有什么意见吗？

Answer 1

当我在婚礼前上舞蹈课时，教练说:“你不必每一步都做得完美，你只需要学会在出现失误时优雅地恢复。如果你能快速做到这一点，并且有一个微笑在你的脸上，没有人会注意到。”

如果您有 100 多个副本，预计您会经常重新初始化副本，可能每天至少一到两个。这是正常的。

所有软件都有错误。坦率地说，期待任何不同是天真的。不要指望软件完美无缺并无限期地 24/7 无错误地继续运行，因为您会失望的。你不应该寻求完美的解决方案，你应该像舞者一样思考，优雅地恢复。

MySQL 复制相当稳定，不亚于其他解决方案。但是可能会发生各种故障，而这并不是 MySQL 的错。

• 由于网络故障，二进制日志可能会在传输过程中产生损坏的数据包。 MySQL 5.6 引入了二进制日志校验和来检测这一点。

• 主实例可能会崩溃并且无法将事件写入二进制日志。 sync_binlog 有助于确保所有事务都在提交时写入二进制日志(尽管有事务开销)。

• 由于不确定的 SQL 语句、数据包损坏或磁盘上的日志损坏，副本数据可能会不同步，或者某些用户可以直接在副本上更改数据。 Percona 的 pt-table-checksum可以检测到这一点，并且pt-table-sync可以纠正错误。使用 binlog_format=ROW 可以减少不确定性更改的可能性。将副本设置为只读会有所帮助，并且不要让用户拥有 SUPER 权限。

• 资源可能会用完。例如，您可以填满主服务器或副本服务器上的磁盘。

• 如果副本跟不上主副本的变化，它们可能会落后。确保您的副本实例没有动力不足。使用 binlog_format=ROW。对单个 MySQL master 写入更少的更改。 MySQL 5.6 引入了多线程副本，但到目前为止，我看到一些情况仍然存在一些问题，因此请仔细测试。

• 副本可以离线很长时间，当它们重新联机时，主服务器的一些二进制日志已经过期，因此副本无法从它停止的地方重播连续的事件流。在这种情况下，您应该丢弃副本并重新初始化它。

• 错误在任何软件项目中都会发生，而 MySQL 的复制也有其份额。您应该继续阅读 MySQL 的发行说明，并准备好升级以利用错误修复。

无论您使用什么品牌的数据库，管理大量连续运行的数据库服务器都需要大量的全职工作。但数据已经成为大多数企业的生命线，因此有必要对这种资源进行管理。 MySQL 并不比任何其他品牌的数据库好，也不差，如果有人告诉您一些不同之处，那么他们就是在卖东西。

P.S.:我想听听您为什么认为在单个 AWS 区域中需要 100 多个副本，因为对于高可用性或扩展的任何目标来说，这可能都过大了一个数量级。