我现在正在使用 AWS RDS 多可用区，效果很好，问题是我希望我的基础设施在区域之间具有容错能力。我正在寻找某种工具来使用 RDS 和我的服务器创建集群。
据我所知，您不能直接从 RDS 集群到另一台服务器，只能读取副本，但不能在区域之间或 AWS 之外进行集群。
我曾经想过每 15 分钟进行一次 mysqldump 或者类似的操作，但是这样做效率不高，而且恢复可能难以维护。
根据您的经验，最好的做法是什么，自己运行 mysql 并使用我的机器配置集群，还是做其他事情。这样，就会有某种不会影响性能的冷复制？我的意思是，每 5 分钟同步一次更改。我可以承受一些数据的丢失，但不能承受停机时间 ;)
任何想法，将是
答案1
答案2
配置您自己的 MySQL 集群（在多个区域进行复制）将耗费大量时间、成本高昂，并且需要专家建议来帮助设置和维护。话虽如此，但它比当前的 RDS 解决方案更可靠（前提是您做得正确），因为它可以承受整个区域故障。
如果您确实需要 100% 的正常运行时间，那么您应该考虑采用自己的解决方案。您有资金、时间和资源来这样做吗？您能负担得起成千上万美元的投资吗？还是说，如果停机时间短一点，会更便宜？
RDS 之前曾遇到过问题（最近一次是在 2012 年）。有趣的是，以下网站报告称，使用“时间点恢复选项”可以大大降低这种风险...
http://www.networkworld.com/news/2012/102312-amazon-outage-263617.html
与 EBS 问题一样，AWS 提醒客户，如果他们启用了时间点恢复选项，那么他们可以使用另一个可用区域中受影响数据库的备份启动新的数据库实例。
另一个选择是确保你有权访问你的备份。例如，如果您有每日备份，您可以将它们发送到 S3 以便于访问（或者如果您比较谨慎，可以每周一次发送到 Amazon 之外）。如果发生 EBS/RDS 故障，您可能能够创建一个新的 RDS 实例，并在 RDS 出现严重问题的情况下从 S3 更快地恢复它。此解决方案假设您可以接受几个小时的停机时间，而不必做大量工作来设计一些疯狂的跨区域解决方案。
最后，根据您的应用程序，尝试利用非关系数据库可能会更便宜。我知道您已经说过您需要一个关系数据库，但是重新设计部分或全部应用程序以使用非关系数据库可能比在多个区域之间滚动您自己的 MySQL 更容易、更便宜（非关系数据库还为您带来其他规模等方面的好处）。这种解决方案并不适合所有人，而且对您来说可能太难了（但是未来的项目可能更容易以这种方式实现！）。