mySQL 表同步
我正在寻找有关从 2 个不同数据库同步 mySQL 表 (myISAM) 的最佳方法的建议。
目前，我们使用 Navicat 将表从生产服务器同步到测试服务器，但我们遇到了很多问题。几乎每天我们都会遇到表同步失败的情况。
我们经常收到下面的错误，更不用说 Navicat 会向我们发送垃圾邮件，其中包含成功和不成功的同步（有没有办法只接收不成功的同步？）。我还知道无论如何更改表都会导致同步失败。因此，无论如何更改表都必须首先对主机进行（这是有道理的，但有什么办法可以解决这个问题吗？）。
-[同步] 完成 - 同步失败：列表索引超出范围 (0)
有什么理由不使用 Navicat 同步吗？我的老板建议使用 mySQL 复制，但我首先关心的是找出为什么我们有这么多问题，因为看起来我们只是滥用同步，从而给我们带来了所有这些问题。
谢谢。
I am looking for suggestions on the best way to sync mySQL tables (myISAM) from 2 different databases.
Currently we use Navicat to sync tables from our production server to our test server but we have been running into many problems. Just about everyday we have been running into a sync failure on a table.
We get the error below a lot of the times, not to mention Navicat spams our e-mails with successful and unsuccessful syncs(is there anyway to just receive only the unsuccessful syncs?). I also know altering the table in anyway will cause a failure to sync. So altering the table in anyway must be done to the master first (This makes sense but is there any way around this?).
-[Sync] Finished - Unsuccessful Synchronization: List index out of bounds (0)
Is there any reason to not use the Navicat sync? My boss suggested using mySQL replication instead but my first concern is finding why we have so many problems because it seems like we just are misusing the sync thus giving us all these problems.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您正在尝试在测试环境中复制生产环境，对吗？
在这种情况下遵循的常见模式是使用
mysqldump之类的工具创建整个数据库的备份，然后将备份导入到测试环境中。通过执行完整备份和恢复，您不仅可以确保至少有一种已知有效的备份方法，还可以确保测试数据库永远不会包含同步的修改工具可能会错过。 （同步工具通常需要每个表上有一个主键或唯一键才能有效运行。）备份和重新导入过程应该很容易实现自动化。在我的工作场所，我们每晚都会执行基于 mysqldump 的数据库转储，并在第二天清晨对每个开发人员的开发环境的个人副本执行可选导入。
It sounds like you're trying to replicate your production environment in your test environment, right?
A common pattern to follow in this situation is using a tool like
mysqldumpto create a backup of the entire database, then later import the backup into the test environment. By doing a complete backup and restore, you're not only ensuring that you have at least one backup method that's known to work, you're also ensuring that the test database can never contain modifications that a sync tool might miss. (Sync tools generally require a primary or unique key on each table to operate effectively.)The backup and reimport process should be an easy thing for you to automate. At my workplace, we perform a
mysqldump-based database dump every night, and perform optional imports into each developer's personal copy of the dev environment early the following morning.