最常见的 MySQL 操作之一是在主服务器和从服务器之间复制数据库。虽然大多数此类连接都可以直接建立和维护，但有时会出现问题：例如，某些主数据可能不会在从服务器上复制，或者读取请求可能会路由到主服务器而不是服务器。寻找复制失败的解决方案有时需要一些额外的侦探工作。
复制是 MySQL 和任何其他数据库中最基本的操作之一：它用于将数据从一个数据库服务器（主服务器）复制到一个或多个其他服务器（从服务器）。该过程通过允许在多个从属服务器之间分配负载以进行读取并限制主服务器进行写入来提高性能。
复制的其他好处是通过从属备份的安全性；分析，可以在不影响主服务器性能的情况下在从服务器上执行；和广泛的数据分发，这是在不需要访问主机的情况下完成的。 （有关复制的更多信息，请参阅 MySQL 参考手册 。）
与数据库管理的任何其他方面一样，复制并不总是按预期进行。 MySQL 参考手册的 故障排除复制 部分指导您在复制出现问题时检查错误日志中的消息。如果错误日志没有为您指出解决方案，请确保通过发出 SHOW MASTER STATUS 语句在 master 中启用二进制日志记录。如果启用，“位置”不为零；如果不是，请确保主服务器正在使用 --log-bin 选项运行。
该手册提供了其他几个复制故障排除步骤：
- master 和 slave 都必须以 --server-id 选项开头，并且每个服务器必须有唯一的 ID 值；
- 运行 SHOW SLAVE STATUS 以确保 Slave_IO_Running 和 Slave_SQL_Running 值均为“yes”；
- 运行 SHOW_PROCESSLIST 并查看 State 列以验证 slave 是否正在连接到 master；
- 如果语句在主服务器上成功但在从服务器上失败，则核选项是进行完整的数据库重新同步，这需要删除从服务器的数据库并从主服务器复制新的快照。 （MySQL 手册中描述了几种不那么激烈的替代方案。）
实际 MySQL 复制问题的解决方案
当 MySQL 指示主从连接正常，但主从上的一些数据没有被复制到从属时，你会怎么做？这就是 2010 年 3 月的 Stack Overflow 帖子中描述的情况。
尽管复制似乎配置正确，但数据并未从主服务器复制到从服务器。资料来源： 堆栈溢出
第一步是在主数据库上运行“show master status”或“show master status\G”以获得从数据库的正确值。上面的从站状态表示从站连接到主站并等待日志事件。同步正确的日志文件位置应该恢复复制到从站。
为确保同步良好，停止主服务器，转储数据库，记录主服务器日志文件位置，重新启动主服务器，将数据库导入从服务器，并以正确的主服务器日志文件位置以从服务器模式启动从服务器。
2014 年 3 月的另一篇 Stack Overflow 帖子介绍了使用 JDBC 驱动程序的主/从设置，其中标记为只读的事务仍在 ping 主服务器。由于 MySQL JDBC 驱动程序正在管理与物理服务器（主服务器和从服务器）的连接，因此连接池和 Spring 事务管理器不知道数据库连接正在链接到多个服务器。
解决方案是将控制权返回给 Spring，然后提交连接上的事务。事务调试消息将指示只要连接处于只读模式，查询就会被路由到从属服务器。通过在连接返回池之前重置连接，只读模式被清除，最后一条日志消息将显示查询现在被路由到主服务器。
新的 Morpheus 虚拟设备 中的点击式仪表板可以轻而易举地诊断和修复异构 MySQL、MongoDB、Redis 和 ElasticSearch 数据库中的复制错误和其他问题。 Morpheus 可让您在短短几分钟内跨混合云无缝配置、监控和分析 SQL、NoSQL 和内存数据库。您创建的每个数据库实例都包含一个免费的完整副本集，用于内置容错和故障转移。
借助 Morpheus 数据库即服务 (DBaaS)，您可以将现有数据库从私有云迁移到公共云，或从公共云迁移到私有。在另一个云中创建相同数据库类型的新实例，实时复制使两个数据库保持同步。访问 Morpheus 站点以 创建一个免费帐户 。
