Mysql远程同步
目前，我们在远程服务器上有一个应用程序，我们的呼叫中心使用该应用程序来执行客户交易。
我们计划在本地服务器上设置 asterisk 来帮助我们完成所有呼叫路由和录音，为了让 asterisk 顺利工作，我们必须将我们的应用程序从远程服务器移动到本地。
将所有数据移动到本地服务器并在本地进行交易很容易，但用户也可以选择在线进行交易，这将影响远程服务器数据库。
我们仍然拥有远程应用程序的原因是由于rackspace提供了可靠的基础设施和备份解决方案。
如果我们将应用程序移动到本地服务器，我正在寻找一种可靠的解决方案来同步远程和本地数据库，以便我们可以处理本地和在线事务。
We currently have an application located on a remote server, and our call center uses this application to perform customer transactions.
We plan to setup asterisk on a local server to help us with all the call routing and recording, for asterisk to work smoothly we have to move our application from the remote server to the local.
Its will be easy to mover all data to the local server and do transactions locally, but there is an option for users to do transactions online too which will hit the remote server database.
The reason we still have the remote application because of the reliable infrastructure and backup solution provided by rackspace.
If we move application to local server i am looking at a reliable solution for syncing remote and local databases so that we can handle local as well as online transactions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不使用 mysql 主主复制并在两端保存最终数据？ （请注意，您必须阅读 auto_increment_increment 和 auto_increment_offset ）
Why not use mysql master-master replication and hold definitive data at both ends? (Note you'll have to do some reading on on auto_increment_increment and auto_increment_offset)
symcbean的回答基本上是正确的。我将这篇文章添加为理解主主复制的一个很好的起点。我进一步推荐 高性能 MySQL 作为深入了解技术和问题的良好参考。
对两个非共置 MySQL 服务器进行写入时，您将不得不面对一些问题。您将需要处理复制延迟，因此数据库不一定完全同步，而只会“最终一致”。此外，如果双方都对内容进行更新，最终可能会出现数据完整性问题。如果您的系统在写入操作中更倾向于插入而不是更新，那么您遇到问题的可能性较小。此外，如果可能修改的数据子集往往位于一台或另一台服务器周围，那么您遇到的问题就会更少。
否则，您可能需要推出自己的解决方案，该解决方案是针对应用程序的特定用例而设计的。
symcbean's answer is basically correct. I'd add this article as a good starting place to understand master-master replication. I'd further recommend High Performance MySQL as a good reference for a deeper understanding of the techniques and issues.
There are some issues that you will have to face doing writes to two non-colocated MySQL servers. You'll have replication lag to deal with, so the databases won't necessarily be completely in sync, but will only be "eventually consistent". Also, if you have both sides doing updates on content, you can end up with data integrity issues. If your system leans towards INSERTs more then UPDATES for the write operations, it is less likely that you'll run into issues. Also, if the subset of data that is likely to be modified tends to be localized around one or the other of the servers, you'll run into fewer issues.
Otherwise, you'll probably want to roll your own solution that is designed towards the specific use cases of your application.