为了解释这个问题的背景：
我们有一个在Linux服务器上运行的本地PHP应用程序（用于运行在线语言学习课程），并在本地主机上使用MySQL来保存用户数据（例如，testing结果，提交工作的标记，花在不同页面上的时间课程等）。
由于我们有来自不同地理位置的学生，因此我们目前在这些地点（西class牙，英国和香港）附近托pipe了3台虚拟服务器，并将用户添加到离他们最近的服务器上（他们通过不同的URL访问，例如europe.domain.com ，uk.domain.com和asia.domain.com）。 这个工作，但是是一个pipe理的噩梦，因为我们必须记住一个特定的用户在哪个服务器上，用户只能连接到一个服务器。 我们希望以某种方式集中化信息，以便所有用户都可以在任何服务器上看到，并且用户可以连接到3台服务器中的任何一台。
问题是，我们应该用什么方法来实现这一点。 这肯定是一个很多人遇到的问题，但是我还没有find任何结论性的search结果。 我看到的最接近的解决scheme是：
像master-master复制，但我已经阅读了这么多的post，这表明这不是一个好主意，因为像auto_increment字段可以打破。
循环复制，这听起来很完美，但引用O'Reilly的高性能MySQL，“一般来说，环是脆弱和最好的避免”
我们不反对在应用程序中重写代码，以使其能够与任何需要的解决scheme一起工作，但我不确定是否使用复制是正确的。
谢谢，
安迪
PS我应该补充一点，我们尝试写入中央数据库，然后使用本地数据库读取，但不同服务器之间写入的响应时间相当糟糕，写入数据立即可用于读取也很重要，所以如果复制太慢，这可能会导致过期的数据被返回。
编辑：我一直在考虑编写我自己的基本复制脚本，这个脚本涉及到每个用户都有一个服务器ID来说明他的“主服务器”，比如亚洲的用户会被标记为香港服务器自己的服务器 然后复制脚本（这将是一个PHP脚本设置为合理频繁地运行，例如每15分钟左右），将独立运行在系统中的每个服务器上。 他们将通过数据库并将有关用户的任何信息与“主服务器”一起分配给运行脚本的服务器，以便将其发送到系统中的所有其他数据库。 他们还需要吸收已经添加到系统上的其他数据库的新信息，其中“主服务器”标志是运行脚本的服务器。 我需要弄清楚细节并构build处理冲突的逻辑，但是我认为这是可能的，但是我想确保没有一个正确的解决scheme已经在那里，因为它似乎是必须的这是很多人已经遇到的问题。
圆形复制，这是简单的主/主/主你的情况将工作。 虽然有些人声称这可能会稍微“脆弱”，任何多服务器设置也是如此。 一个体面的监控系统，无论如何都应该是整个软件包的一部分，这将有助于尽早发现问题，以便在出现严重问题之前解决问题。
自动递增“问题”是如此容易规避，我不能相信人们仍然提出这个问题。 简单地在每台服务器上启动一个不同数量的计数器，并且使用至less与服务器数量一样大的步骤，留下足够的空间用于未来可能的添加。
对于您的应用程序来说，听起来像是循环复制（其中多主机是特殊情况）应该不是太大的问题。
auto_increment问题很容易通过auto_increment_increment和auto_increment_offset解决 。
在频率相对较高的所有实体上监视复制，并修复引起复制中断或数据漂移的任何事件的来源 。 Maatkit的mk-table-checksum和mk-table-sync对于识别漂移数据非常有用 。 得到二进制日志和代码来确定来源… 🙂
我们不反对在应用程序中重写代码，以使其能够与任何需要的解决scheme一起工作，但我不确定是否使用复制是正确的。
您所描述的问题听起来像是按需用户转移的情况。
这听起来似乎是不可接受的，为所有用户创build一个延迟（不可避免与地理上不同的服务器），所以给你的用户一个“导出configuration文件”或“传输”选项，并写一个function，将用户数据从一台服务器下一个点播。
编辑： …当你在这里，也许你可以添加一个后缀到你的每个实例的用户名，所以用户可以指示（通过提供他们的用户名）他们的帐户在他们的请求帮助时注册了哪个服务器。
我也使用了复制环模型，并且由于脆弱的方面而具有成功和问题。 一个响铃最大的问题是失去一台服务器将停止所有数据stream动。
如果你有实时监控，你可以使用CHANGE MASTER TO来保持环的存在（你必须先停止从机）。 这使您可以从主 – 主 – 主 – 主 – 主 – 主转换回来。 这只会与一个主动的故障转移机制相结合，这个机制可以将用户引导到一个活动的站点，而不是“本地”（当前处于closures状态）。
我只有两个站点，并且在每个站点有两台服务器（而不是您的单服务器每站点模型）。 在我们的案例中，一个潜在的解决scheme是在支持每个站点MySQL实例的每个站点上创build一个MySQL NDB集群，并在MySQL实例中设置一个复制环。 这意味着失去一个站点（或站点之间的通信）将不需要任何紧急变更，一旦失败的站点恢复，一切都会恢复。
如果您愿意重新devise您的数据访问层和数据模型，而且您愿意将数据存储在服务器之外的其他位置，则可以尝试使用分布式数据库服务，例如http://aws.amazon.com/simpledb /
让我们考虑一个简单的场景，其中所有数据库服务器（服务器1，服务器2和服务器3）在地理位置上位于通过VPN或其他networking链接失败的不同站点上。 我们安排每10分钟一次主人更换。
为了这个可能，我们必须停止奴隶，把主人换成新的服务员。 基本上，每个数据库上的主机IP地址是循环轮转，但要记住停止从机，更换主机，然后启动从机。
每个服务器的伪代码脚本如下所示：
脚本1执行10分钟，然后链接到脚本2：
脚本2执行了10分钟，然后链接到脚本1：
脚本1执行10分钟，然后链接到脚本2：
脚本2执行了10分钟，然后链接到脚本1：
脚本1执行10分钟，然后链接到脚本2：
脚本2执行了10分钟，然后链接到脚本1：
这就像主人之间的预定同步。
任何意见都是最受欢迎的。