我们正在将社交媒体服务转移到独立的数据中心，因为我们的其他托管服务提供商的整个数据中心都已关闭。两次。
这意味着两个网站都需要在某种意义上进行同步 - 我不太担心页面的代码，这很容易同步，但是它们需要具有相同的数据库数据。
根据我对SO的研究，似乎MySQL Replication是一个不错的选择，但MySQL手册，用于扩展，表示当有更多的读取，然后有写入/更新时它是最好的： http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-scaleout.html
在我们的案例中，它大致相同。我们现在每天要求大约200到300万个请求，我们可以快速增长。每个请求都是读写请求。
处理此问题的最佳方法或工具是什么？
答案 0 :(得分：0)
复制不是即时的，并且所有写入都必须通过线路发送到远程服务器，因此它也需要带宽。只要这对您有用并且您了解后果，那么不要担心读/写比率。
但是，您确定需要全局复制吗？我们处理数百万个请求并拥有一个位置，多个Web服务器连接到两个数据库。一个数据库是实时数据库，另一个是复制的只读数据库。
我们确实有全局故障转移位置，有些人在任何一天连接到这些，即使我们的主节点因为他们有Internet问题而启动。然而，数据只是涓涓细流。
如果主节点发生故障，那么每个机构都将按顺序使用全局故障转移位置。因此，如果我们的主节点死亡，所有客户都将连接到丹佛。如果丹佛下台，他们都会连接到哥伦布。
此外，我们的主节点位于两个不同的互联网提供商上，因此一个ISP关闭不会让我们失望。
答案 1 :(得分：0)
两个数据中心之间的连接速度是否足够好？您可以将文件复制到新服务器并在那里移动数据库。然后设置旧服务器，以便它将连接到另一个DC的新服务器的MySQL数据库？这当然会慢一些，但根据查询的性质，这是可以接受的。只要DNS或其他任何移动/完成，您只需在没有更多请求时关闭旧服务器。
答案 2 :(得分：0)
为帮助您评估选项，您需要考虑灾难恢复方案中的要求（即在一个数据中心内完全丢失系统）。
特别是对于这种情况，您可以承受多少数据丢失（恢复点目标 - RPO），以及您需要多长时间才能使站点的备用数据中心版本启动并运行（恢复时间目标 - RTO）。
例如，如果你的RPO在5分钟内没有交易丢失和恢复，那么解决方案将与你能承受损失5分钟的交易和一小时的恢复不同。
我要问的另一个问题是你是否正在使用SAN存储？这为您提供了在存储级别（SAN阵列到SAN阵列）的复制选项，而不是在数据库级别（例如MySQL复制）。
还要考虑数据中心之间的距离（例如，您可以为两个数据库执行同步写入，或者异步复制方法更合适）