如何解决实际的MySQL复制问题

共计 1466 个字符，预计需要花费 4 分钟才能阅读完成。

这篇文章主要为大家展示了“如何解决实际的 MySQL 复制问题”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“如何解决实际的 MySQL 复制问题”这篇文章吧。

MySQL 最常见的操作之一就是在主服务器和从服务器之间复制数据库。虽然大多数此类连接都很容易建立和维护，但有时也会出现问题，例如某些主数据可能无法在从属设备上复制或者读取请求可能会路由到主设备而不是服务器。

问题出现很容易，但是想要找到解决复制失败的方法却需要我们花些心思。

复制是所有数据库的最基本操作，它主要是将数据从一个数据库服务器 (主服务器) 复制到一个或多个其他数据库(从服务器)。该过程通过允许在多个从属服务器之间分配负载来进行读取、通过将主服务器限制为写入来提高性能。

复制的好处包括通过从备份来提高安全性; 分析可以在从数据库执行且不影响主数据库的性能表现; 广泛的数据分发，无需访问主数据即可完成……

和很多数据库管理操作一样，复制有时也会不按预期进行，MySQL 参考手册中的“复制故障排除”提示了我们当复制出现问题时，应该检查错误日志中的哪些信息。如果错误日志未指向解决方案，可通过发出 SHOW MASTER STATUS 语句在主服务器中启用二进制日志记录，如果已启用，那么“status”不为零，如果没有，请确保主服务器正在运行 –log-bin 选项。

除此之外，该手册还提供了其他几个复制故障排除步骤：

主服务器和从服务器都必须以 –server-id 选项启动，并且每个服务器必须具有唯一的 ID 值;

运行 SHOW SLAVE STATUS 以确保 Slave_IO_Running 和 Slave_SQL_Running 值均为“yes”;

运行 SHOW_PROCESSLIST 并查看 State 列以验证从站是否正在连接到主站;

如果一个语句在主服务器上成功但在从服务器上失败，那么核心选项是执行完整的数据库重同步，这需要删除从服务器的数据库并从主服务器复制一个新的快照。

解决实际的 MySQL 复制问题

当 MySQL 主从连接有序时，为什么主设备上的数据没有被复制到从设备上呢? 我们以 Stack Overflow 帖子中提到的问题为例，来看看实际的 MySQL 复制问题应该如何解决。

第一步是在 master 数据库上运行“show master status”或“show master status \ G”以获取从站的正确值，根据上图反映的从站状态，从站已连接到主站并等待日志事件。同步正确的日志文件位置应该恢复到从服务器的复制。

为了确保良好的同步，停止主日志文件，转储数据库，记录主日志文件的位置，重新启动主日志文件，将数据库导入从模式，并以正确的主日志文件位置启动从模式。

2014 年 3 月发布的另一个 Stack Overflow 帖子提供了使用 JDBC 驱动程序的主 / 从设置，其中标记为只读的事务仍在 ping 主设备。由于 MySQL JDBC 驱动程序正在管理与物理服务器 (主服务器和从服务器) 的连接，因此连接池和 Spring 事务管理器不知道数据库连接是否链接到多个服务器。

解决方案是将控制权返回给 Spring，之后提交连接上的事务。事务调试消息将指示，只要连接处于只读模式，查询将被路由到从服务器。通过在连接返回到池之前重置连接，清除只读模式，最后一条日志消息将显示查询现在正被路由到主服务器。

以上是“如何解决实际的 MySQL 复制问题”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！