我工作的内部开发软件通过我们的devexpress orm（XPO）直接连接到我们办公室的mysql服务器。表现很棒。
我们正在开设另一个办事处......越野。表现：不太好。要求是软件在两个办公室都像在办公室一样响应，并且一个办公室的数据可以实时地向另一个办公室提供。
这种规模对我来说是全新的。我并不反对聘请一位曾经做过类似事情的顾问，但我想先了解一下这些选项。我确信这是一种常见的情况。
复制是个好主意吗？它足够快吗？足够稳定吗？
如果复制不起作用，是否有解决此类情况的开发模式？
哎呀，我甚至不确定如何标记这个，所以如果有人知道更好......请随时重新标记
编辑＆gt;有关数据的详细信息
我想，与某些企业软件相比，我们并没有移动大量数据。该软件管理客户帐户，约会等，每个用户工作约2-5个单独的帐户/分钟（当前50个用户，计划扩展后200-400），每次更新数据。
当办公室A中的某人为办公室B中的某人创建约会时，实时方面就会发挥作用，理想情况下，他需要能够立即查看其详细信息（<2分钟）。也就是说，每条记录通常每天最多只变异5次。但这只是我怀疑的;我实际上没有关于我的任何使用情况统计数据。
答案 0 :(得分：1)
你们最后一个度假村当然要确保所有繁重的工作都是在后台线程中完成的，这样就不会阻止GUI线程。
实时数据取决于数据，我想念一个详细的描述，例如我们在每个请求中谈论了多少数据（即对象有多大），你的互联网连接速度有多快（可能是瓶颈？），是mysql服务器和你控制良好配置之间的所有基础设施？数据的静态/动态如何，如果实时数据每天变异一次或每天变异数十亿次对于“解决方案”非常重要
答案 1 :(得分：1)
如果不创建无法解决和破坏的复制冲突，则无法在两个方向上使用异步复制。
因此，您明显的选择是使用读/写拆分 - 让应用程序从（只读）本地DB执行非关键读取，并将所有写入指向主控。这样做的缺点是，这意味着你无法立即回读自己的写作。
MySQL复制并不完美，需要一些努力来设置和持续监控才能维护;你必须经常检查从属数据是否相同。某些查询被错误地复制;你需要了解这些并避免它们。