我们正在将EC2上的networking服务器networking扩展到许多不同的地区，目前使用主/从复制。 我们发现，在过去的几个月中，我们的从服务器已经停止了多次复制，这要求我们清除数据库并重新初始化复制。
现在我们正在寻找在3个不同地区有服务器，我们有点担心这些MySQL复制错误。 我们相信他们是由于auto_increment价值，所以我们正在考虑一些方法来平息这些错误，并稳定复制：
auto_increment补偿，定期备份到S3。 要么， 经过调查，似乎他们都有缺陷（前者的复制错误，后者的性能问题）。
我们相信集群方法将允许我们比Multi-Master路由更容易地pipe理和添加新节点，并将减less/消除我们目前看到的复制问题。 但是，性能是重中之重。
MySQL-Cluster的性能问题和人们说的一样糟糕吗？
如果你理解你的数据以及复制失败的原因，你不需要重新加载从服务器，尽pipe这样做通常是最简单的方法，因为可以很费时地修复从服务器，以便复制可以继续。
我已经使用了多个主人几年了，我遇到的问题主要是由触发器造成的，这些触发器真的很难debugging。 出于这个原因，我会尽可能地使事务成为primefaces和确定性的，并将用户或会话locking到最本地的数据库。
我使用可用dbs的查找表，以用户的十进制ip地址模数为索引，以便用户始终可以看到一个数据库，并且不受由db跳转引起的复制滞后的影响，就像mysql-proxy所做的一样。
通过ssh隧道或encryption的vpn作为一个环连接，它应该只是所有的工作。
在环中插入另一个数据库非常简单，但是如果有任何复制滞后，那么删除一个数据库就会产生昂贵的循环风险，可能会在被注意之前插入或更新logging数百万次！
我会去复制 – 它运作良好。 您可以挂起每个主服务器的更多从服务器进行报告和时间点备份，而无需停机。
MMM带来更多的问题比解决，相信我。
MySQL集群：我不知道新的7.2，但我知道你不能让他们太遥远。 能够使用VM中的节点是7.2的一个新特性，所以您可以掌握时序如何杀死所有事物。
提高数据库性能并不能certificate新问题的数量。 我build议使用less量的CPU和硬件RAID或SSD保持单台服务器。
MMM （用于MySQL的多主复制pipe理器）可以节省很多时间。