MySQL主从复制的可靠性

Question

我有一个应用程序需要一个大约30个表的主目录,需要将其复制到应用程序的许多(100+)个从属副本.从站可能位于其自己的数据库实例中,或者在单个数据库实例中可能有多个从站.对主目录的任何更改都需要在合理的时间内(大约5分钟)复制到从属目录.我们的基础架构都是AWS EC2,我们使用MySQL.主服务器和从服务器都将驻留在单个AWS区域内.

我曾计划使用Master-Slave复制,但我看到有关MySQL复制的报告有时不可靠,我不确定这是由于特定实现中固有的失败还是MySQL本身的失败.我们需要一个高度自动化和可靠的系统,可能我们必须开发监控脚本,允许从站连续监控其相对于主站的目录.

任何观察？

Answer 1

当我在婚礼前上舞蹈课时,导师说:"你不必完美地完成每一步,你必须学会​​在失误发生时优雅地恢复.如果你能快速做到,那就带着微笑面对,没有人会注意到."

如果你有100多个奴隶,期望你经常重新初始化奴隶,可能每天至少有一两个奴隶.这个是正常的.

所有软件都有错误.坦率地说,期待任何不同的东西是天真的.不要指望软件完美无瑕并且无限期地无限期地全天候运行,因为你会感到失望.你不应该寻求一个完美的解决方案,你应该像舞者一样思考并优雅地恢复.

MySQL复制相当稳定,并且不逊于其他解决方案.但是,如果没有MySQL的错误,可能会发生各种各样的故障.

• 由于网络故障,Binlog可能会在传输过程中产生损坏的数据包.MySQL 5.6引入了binlog校验和来检测这一点.

• 主实例可能崩溃并且无法将事件写入binlog.sync_binlog可以帮助确保在提交时将所有事务写入binlog(尽管具有事务开销).

• 由于非确定性SQL语句或数据包损坏或磁盘上的日志损坏,从属数据可能会失去同步,或者某些用户可以直接在从属服务器上更改数据.Percona的pt-table-checksum可以检测到这一点,而pt-table-sync可以纠正错误.使用binlog_format=ROW减少了非确定性变化的机会.设置从站read-only可以提供帮助,并且不要让用户拥有SUPER权限.

• 资源可能耗尽.例如,您可以填写主服务器或从服务器上的磁盘.

• 如果他们无法跟上主人的变化,奴隶可能会落后.确保您的从属实例没有电源不足.使用binlog_format=ROW.将更少的更改写入单个MySQL主服务器.MySQL 5.6引入了多线程从属,但到目前为止我已经看到了一些仍然有点错误的情况,因此请仔细测试.

• 从站可以在较长时间内脱机,当它们重新联机时,一些主站的binlog已经过期,因此从站无法从停止的位置重放连续的事件流.在这种情况下,您应该废弃奴隶并重新初始化它.

• 任何软件项目都会出现错误,MySQL的复制已经分享了.您应该继续阅读MySQL的发行说明,并准备升级以利用错误修复.

无论您使用何种类型的数据库,在连续操作中管理大量数据库服务器都需要大量的全职工作.但数据已成为大多数企业的生命线,因此有必要管理这些资源.MySQL并不比任何其他品牌的数据库更好,也不差,如果有人告诉你不同的东西,他们就会卖东西.

PS:我想知道为什么你认为在一个AWS区域中需要100多个奴隶,因为对于任何高可用性或扩展目标而言,这可能是一个数量级的过度杀伤.