我有一个应用程序，它需要大约30个表的主目录，这些表必须复制到该应用程序的许多（100+）从属副本中。从站可能在自己的数据库实例中，或者单个数据库实例中可能有多个从站。对主目录的任何更改都需要在合理的时间（大约5分钟）内复制到从站。我们的基础架构全部是AWS EC2，我们使用MySQL。主服务器和从服务器都将驻留在单个AWS区域中。
我曾计划使用主从复制，但是我看到有关MySQL复制的报告有时不可靠，而且我不确定这是否是由于特定实现固有的故障或MySQL本身的故障所致。我们需要一个高度自动化和可靠的系统，可能是我们必须开发监视脚本，以使从属服务器可以连续监视其相对于主服务器的目录。
任何观察结果？
[当我在婚礼前上舞蹈课时，教练说：“您不必完美地完成每一步，只要有失误，您就必须学会优雅地恢复。如果您可以迅速地微笑着在你脸上，没人会注意到。“
如果您有100多个副本，那么您可能会频繁地重新初始化副本，可能每天至少重复一两个。这很正常。
所有软件都有错误。坦率地说，期待任何不同都是天真的。不要指望软件是完美无缺的，并且可以无限期地连续24/7运行，不会出错，因为您会失望的。您不应该寻求完美的解决方案，而应该像舞者一样思考并优雅地康复。
MySQL复制是相当稳定的，并且比其他解决方案要稳定。但是，如果不是MySQL的错，可能会发生各种失败。
Binlog可能会由于网络故障而在传输过程中产生损坏的数据包。 MySQL 5.6引入了binlog校验和来检测到这一点。
主实例可能会崩溃，并且无法将事件写入二进制日志。 sync_binlog可以帮助确保所有事务在提交时都被写入二进制日志（尽管有事务开销）。
复制数据可能由于不确定的SQL语句，数据包损坏或磁盘上的日志损坏而失去同步，或者某些用户可以直接在副本上更改数据。 Percona的pt-table-checksum可以检测到此错误，而pt-table-sync可以纠正错误。使用binlog_format=ROW减少了不确定性更改的机会。设置副本read-only会有所帮助，并且不要让用户拥有SUPER特权。
资源可能用完。例如，您可以填满主服务器或副本服务器上的磁盘。
复制品可能会落后，如果他们跟不上母版上的更改。确保副本实例的电源未不足。使用binlog_format=ROW。减少对单个MySQL主数据库的更改。 MySQL 5.6引入了多线程副本，但是到目前为止，我已经看到了一些仍然存在问题的情况，因此请仔细测试。
Replicas可以长时间脱机，当它们重新联机时，某些主服务器的binlog已过期，因此该副本服务器无法从中断的地方重播连续的事件流。在这种情况下，您应该丢弃副本并重新初始化它。
错误在任何软件项目中都会发生，而MySQL的复制也占有一席之地。您应该继续阅读MySQL的发行说明，并准备进行升级以利用错误修复。
无论您使用哪种品牌的数据库，在连续运行中管理大量数据库服务器都需要大量的全职工作。但是数据已成为大多数企业的命脉，因此必须管理此资源。 MySQL并不比任何其他品牌的数据库都好，也不比它差，如果有人告诉您一些不同的东西，那么他们在卖东西。
P.S .：我想听听为什么您认为在一个AWS区域中需要100个以上的副本，因为对于任何高可用性或可扩展的目标来说，这可能会造成一个数量级的杀伤力。