我有一个应用程序需要一个大约30个表的主目录，这些表需要复制到应用程序的许多（100+）个从属副本。从站可能位于其自己的数据库实例中，或者在单个数据库实例中可能有多个从站。对主目录的任何更改都需要在合理的时间内（大约5分钟）复制到从属目录。我们的基础架构都是AWS EC2，我们使用MySQL。主服务器和从服务器都将驻留在单个AWS区域内。
我原本计划使用Master-Slave复制，但我看到有关MySQL复制的报告有时不可靠，我不确定这是由于特定实现中的固有缺陷还是MySQL本身的失败。我们需要一个高度自动化和可靠的系统，可能我们必须开发监控脚本，允许从站连续监控其相对于主站的目录。
有任何意见吗？
答案 0 :(得分：6)
当我在婚礼前上舞蹈课时，导师说：“你不必完美地完成每一步，你必须学会在失误发生时优雅地恢复。如果你能快速做到这一点，那么你脸上露出笑容，没有人会注意到。“
如果你有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引入了多线程从属，但到目前为止我已经看到了一些仍然有点错误的情况，所以要仔细测试。
Slaves可以长时间离线，当他们重新上线时，一些主人的binlog已经过期，因此奴隶无法从中断的地方重播连续的事件流。在这种情况下，您应该删除奴隶并重新初始化它。
任何软件项目都会发生错误，MySQL的复制已经分享了。您应该继续阅读MySQL的发行说明，并准备升级以利用错误修复。
无论您使用什么类型的数据库，在连续操作中管理大量数据库服务器都需要大量的全职工作。但数据已成为大多数企业的生命线，因此有必要管理这些资源。 MySQL并不比任何其他品牌的数据库更好，也不差，如果有人告诉你不同的东西，他们会卖东西。
P.S。：我想知道您认为在一个AWS区域中需要100多个奴隶的原因，因为对于任何高可用性或扩展目标而言，这可能有点过分。