我们正在将 EC2 上的 Web 服务器网络扩展到多个不同的区域，目前使用主/从复制。我们发现，在过去的几个月里，我们的从服务器多次停止复制，这需要我们清除数据库并再次初始化复制。
由于我们现在希望在 3 个不同的区域部署服务器，因此我们有点担心这些 MySQL 复制错误。我们认为这些错误是由auto_increment值引起的，因此我们正在考虑多种方法来消除这些错误并稳定复制：
- 多主复制；3 个主服务器（每个区域一个），具有相关
auto_increment偏移量，定期备份到 S3。或者， - MySQL 集群；3 个节点（每个区域一个），带有一个单独的管理节点，该管理节点也将汇总日志和统计数据。
经过调查后发现它们都有缺点（前者有复制错误，后者有性能问题）。
我们相信，与多主路由相比，集群方法可以让我们更轻松地管理和添加新节点，并减少/消除我们目前看到的复制问题。但性能是首要考虑因素。
MySQL-Cluster的性能问题是否像人们所说的那么严重？
答案1
如果您了解您的数据和复制失败的原因，那么您不需要重新加载从属服务器，尽管这通常是最简单的方法，因为修复从属服务器以使复制能够继续可能很乏味。
我已经使用多个主服务器几年了，我遇到的问题主要是由触发器引起的，而触发器很难调试。因此，我会让事务尽可能原子化和确定性，并将用户或会话锁定到最本地的数据库。
我使用一个可用数据库的查找表，该表由用户的十进制 IP 地址的模数索引，以便用户始终看到一个数据库，并且不会受到数据库跳跃导致的复制滞后的影响，就像 mysql-proxy 以前那样。
通过 ssh 隧道或加密 vpn 以环的形式进行连接，一切就都能正常工作。
将另一个数据库插入环很简单，但如果存在任何复制滞后，删除一个数据库会带来昂贵循环的风险，可能会在被发现之前插入或更新记录数百万次！
我会选择复制 - 它在正常工作时效果很好。您可以挂载每个主服务器的更多从服务器，用于报告和时间点备份，而无需停机。
答案2
相信我，MMM 带来的问题比它解决的问题还多。
MySQL Cluster：我不知道新版 7.2 的情况，但据我所知，您不能将它们放得太远。7.2 的一项新功能是能够在虚拟机中使用节点，这样您就可以了解时间如何终止一切。
答案3
- 主-主模式下会遇到更多问题，尤其是在高端系统上
- 数据一致性可能存在的问题
提高数据库性能并不能证明新问题的数量是合理的。我建议保留一台服务器，配备少量 CPU 和硬件 RAID 或 SSD。
嗯（MySQL 的多主复制管理器）节省了大量时间。