考虑一个拥有2个前端服务器的相当大的网站（2M +浏览量/ m，大量用户）：美国的一台前端服务器，欧洲的一台。两个专用URL将访问者带到一个服务器上，一个用法语，另一个用英语。两个站点共享完全相同的数据。
什么是最具成本效益的解决方案？ （在我公司使用的数据库：MySQL）
1 / Amazon EC2（美国）上的单个主服务器，以及前端服务器上的从属服务器？
优点：没有master-master rep，意味着没有数据与自动增量和独特列上的重复等冲突的风险。
缺点：滞后！当你在欧洲时，在美国写作会不会有太多的滞后？ 另一个缺点可能是在主模具死亡时缺少快速的脏溶液。那么奴隶在同一台服务器上怎么样呢？
2 /两个Amazon EC2实例，一个在美国，一个在欧洲，充当主 - 主复制服务器。在每个前端加上两个奴隶？
高级：数据的速度和安全性。当然没有负载均衡器，但是将主服务器切换到另一个主服务器似乎非常简单。
Drwbcks：价格。以及DB上的腐败风险
3 /任何其他解决方案？
由于这是我第一次使用两大洲的服务器，我非常感谢您从该领域的经验中学习，包括是否包括MySQL，包括是否包括EC2。
由于 马歇尔
答案 0 :(得分：3)
像往常一样，我要说的取决于你的应用程序，它如何使用数据库等等。你需要问问自己：
我假设法国服务器在欧洲，而英语服务器在美国？如果您可以对数据进行分区，以便法语站点使用一个数据库而英语站点使用另一个数据库，那么您的状况会更好。即使两个站点都访问两个数据库，因为您不必担心冲突。您甚至可以在每个主服务器上运行两个mysql实例，并为两者执行多主机复制。
如果你不能进行分区，我可能会选择＃2，但我会将其中一台机器指定为“真正的”主机，并将所有写入内容发送给它以帮助避免数据崩溃。通过这种方式，可以轻松切换。
如果您对成本敏感并且无论如何都要在前端服务器上运行副本，只需在前端服务器上运行主数据库。你可以随时把它拉下来。副本通常比拥有相同读取负载的主机具有更高的CPU / IO成本：它们必须以串行方式执行它们的写入，这可能会使事情搞砸。
另外，不要为数据库使用m1.small实例。或者至少留意你的表现。 m1.smalls显着不足，如果你看{4}，你会发现你的CPU时间有很大一部分被虚拟机管理程序窃取。我推荐c1.medium's。
答案 1 :(得分：2)
永远不要使用master-master复制。没有解决冲突的机制。如果您尝试同时写入两个主服务器（或者在写入之前写入另一个主服务器的更改之前写入一个主服务器），那么最终会出现一个损坏的复制方案。服务不会停止，他们只会越走越远，无法实现和解。
如果没有经过精心设计的监控，请不要使用MySQL复制来检查它是否正常工作。不要假设因为你最初正确配置它会继续工作，或保持同步。
DO有一个记录良好，经过充分测试的程序，用于恢复从不同步或停止的奴隶。有一个类似的文档化程序，可以从头开始安装新的从站。
如果您关心正确或最新的数据，您的应用程序可能需要足够的智能才能知道从属设备不同步或停止，并且不应使用它。您需要从监控中获得某种反馈才能执行此操作。
如果您的主人在欧洲时有一个奴隶，比如美国，那通常会给您预期的延迟，即比他们共处的时间大150分钟。
在MySQL中，从服务器在主服务器完成之前不会启动查询，因此它将始终落后于更新所需的时间长度。
此外，奴隶是单线程的，因此单个“硬”更新查询将延迟所有后续查询。
如果你在多线程写入负载上推动你的主人，假设你的奴隶有相同的硬件，他们就不太可能跟上。
答案 2 :(得分：1)
我们正在研究一个类似的情况 - 亚马逊东海岸本周完全被网络切断两次 - 这意味着甚至不能在多个地区复制并使用RDB实例保持可用。
但DRB不允许从东到西，甚至到欧洲。
我们现在正在审查Master Master在东西方甚至欧洲的做法，其中一位主人仅作为故障转移，并通过dnsmadeeasy进行故障转移，响应速度极快。
优点：快速可靠的故障转移，短暂的停机时间，无需复杂的故障转移功能管理。
缺点：一个额外的系统在不使用它的情况下运行 - 但与使用不那么昂贵的RDB相比
亚马逊很好地管理DRB，包括时间点恢复等等 - 所有这些都是通过切换它而丢失的。但事实是它仅限于一个区域内的复制，并且该区域可以完全切断，这使得它成为问题。作为RDB备份的替代方案，我们正在研究Zmanda开源工具来处理备份管理。尚未经过测试，但基于我们所有的故障转移，数据库和硬件，所以这看起来是最简单，因此最有希望的高可用性方法。
答案 3 :(得分：0)
这个问题很老，但现在解决方案存在：加莱拉。它执行MySQL（InnoDB）复制，并且也适用于WAN。 http://codership.com/