主页 / dba / 问题 / 218401
Accepted
IGGt
Asked: 2018-09-25 01:42:56 +0800 CST

MySQL 复制停止，但仍然说它正在运行

  • 772

我有一个奇怪的复制问题。作为参考，我将 MySQL 5.5 与基于语句的复制一起使用。我们在站点 A / 网络 A 上有一个主站和从站，在站点 B / 网络 B 上有一个从站。

网络 A 上的一切都很好。问题发生在站点 B/网络 B 上连接到站点 A 主服务器的数据库上。

现在有几次我看到站点 B 的数据库上的复制停止了。如果我看一下SLAVE_IO_RUNNING他们都说. 在所有程度上和目的上，一切对我来说都很好。但是，我的监控报告说我们运行的心跳事件落后了。就好像从站连接到主站，但没有接收到任何数据。SLAVE_SQL_RUNNINGSHOW SLAVE STATUSyes

各种pos值 ( read_master_log_pos, relay_log_pos, exec_master_log_pos) 都是静止不动的。我还检查了其中一个的中继日志，那时传入的数据就停止了。

如果我同时查看主数据库和从数据库，则没有长时间运行的查询会导致这种情况。一切似乎都按预期运行，并且如前所述，站点 A 的从站都很好并且保持最新状态。

有问题的数据库都在运行不同的查询，所以它不是特定的查询令人不安的事情。

MySQL 的错误日志中没有任何内容。

我们模拟了一次短暂的网络故障（尽管从我们的监控中我们看不到这些时间有任何网络中断）并且数据库按预期工作。一旦网络重新连接，它们就会恢复复制。

这是通过运行来解决的stop slave; start slave;，此时一切都继续进行，就好像什么都没发生过一样。

还有其他人遇到过类似的问题吗？或者可以阐明可能发生的事情。我的直觉是有一个非常短暂的网络中断，太短以至于监控无法捕捉到，但我不知道为什么这会扰乱 MySQL。

mysql replication

1 个回答

  1. Best Answer

    引起我注意的是“NETWORK”这个词。

    Master 和 Slave 之间的通信是双向的。

    根据MySQL 复制文档

    二进制日志转储线程。 当从服务器连接时，主服务器创建一个线程将二进制日志内容发送给从服务器。这个线程可以在 master 上的 SHOW PROCESSLIST 输出中识别为 Binlog Dump 线程。

    二进制日志转储线程在主服务器的二进制日志上获取一个锁，以读取要发送给从服务器的每个事件。一旦事件被读取，锁定就被释放，甚至在事件被发送到从属之前。

    从 I/O 线程。 当在从服务器上发出 START SLAVE 语句时，从服务器创建一个 I/O 线程，该线程连接到主服务器并要求它发送记录在其二进制日志中的更新。

    slave I/O 线程读取 master 的 Binlog Dump 线程发送的更新（见上一项）并将它们复制到包含 slave 中继日志的本地文件。

    此线程的状态在 SHOW SLAVE STATUS 的输出中显示为 Slave_IO_running，或在 SHOW STATUS 的输出中显示为 Slave_running。

    鉴于此对复制的 I/O 方面的描述，您可以寻找什么？？？

    防火墙

    Master和Slave之间的连接需要打开防火墙。不幸的是，我曾见过防火墙在主服务器上打开而从服务器照常连接的情况。Slave 会让 I/O 线程显示在进程列表中，就像没有任何错误一样。大师也会这样做。突然间，60 秒后，I/O 线程从 Master 的进程列表中消失，但在 Slave 上仍然可见。

    鉴于这种情况（我在两个不同的 AZ（可用区）中的两个 Amazon EC2 服务器之间目击），当时的解决方案是检查安全组并在从属 AZ 中打开端口 3306。

    暂停

    MySQL 有网络连接超时的设置

    来自 MySQL 文档：

    • rpl_semi_sync_master_timeout：一个以毫秒为单位的值，它控制主服务器在超时和恢复到异步复制之前等待从服务器确认提交的时间。默认值为 10000（10 秒）。只有安装了主端半同步复制插件，此变量才可用。
    • net_read_timeout：在中止读取之前等待来自连接的更多数据的秒数。当服务器正在从客户端读取时，net_read_timeout是控制何时中止的超时值。当服务器正在向客户端写入时，net_write_timeout是控制何时中止的超时值。另见slave_net_timeout。
    • net_write_timeout：在中止写入之前等待将块写入连接的秒数。另见net_read_timeout。
    • slave_net_timeout：在 slave 认为连接断开、中止读取并尝试重新连接之前等待来自 master 的更多数据的秒数。第一次重试在超时后立即发生。重试之间的间隔由 CHANGE MASTER TO 语句的 MASTER_CONNECT_RETRY 选项控制，重新连接尝试的次数由 --master-retry-count 选项限制。在 MySQL 5.7.7 之前，默认值为 3600 秒（一小时）。在 MySQL 5.7.7 及更高版本中，默认值为 60 秒（一分钟）。

    担忧

    为什么要这样谈论网络？？？您可能会以数据漂移的形式成为受害者。回来Jun 17, 2014，我回答了我的任务是 Mysql Master-Master 复制的帖子？. 我简要提到网络是数据漂移中的无名英雄：

    • 联网
      • 您必须确保网络流量没有被淹没，您的交换机没有问题，任何绕过网络的交叉布线没有缺陷，没有丢包。
      • 对于MySQL来说，Replication I/O线程是依赖于网络的。您必须确保 mysqld 可以定期对它的主节点进行心跳。也许可以为此安装和配置半同步复制。

    你的实际问题

    您运行STOP SLAVE;并START SLAVE没有找到根本原因，但确实解决了手头的问题。如何 ？？？所有这一切都是断开 I/O 和 SQL 线程，然后从头开始重新连接。

    你也可以这样做

    STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

    这也很好，特别是如果 SQL 线程很忙并且您不想中断它。

    您将需要检查主站和从站之间的连接是否有丢包。

    如果您的监控具有与 MySQL 超时值相同的时间粒度，那么当它确实发生时您没有任何提醒。您将不得不更频繁地轮询 MySQL。作为替代方案，您可能会创建某种 SNMP 设置来监视 MySQL，因此如果来自 SNMP 的信息没有及时更新，您可以检测到 MySQL 已关闭或没有响应，而无需连接到 MySQL。

    我的回答可能没有完全说明根本原因，但我有两个建议：

    建议 #1

    查看您的max_allowed_pa​​cket设置。在 DBA StackExchange 中，我曾多次亲切地称呼 MySQL 数据包the Silent Killer of DB Connections。I/O 线程与 DB Connection 一样多。我会确保max_allowed_pa​​cket始终设置为 1073741824（即 1G）。

    建议#2

    您可以手动设置 I/O 线程心跳。如何 ？

    根据MySQL 5.5 文档CHANGE MASTER TO

    MASTER_HEARTBEAT_PERIOD 设置复制心跳之间的间隔（以秒为单位）。每当 master 的二进制日志更新一个事件时，下一次心跳的等待时间就会重置。interval 是一个十进制值，范围为 0 到 4294967 秒，分辨率为毫秒；最小的非零值是 0.001。只有当二进制日志文件中没有未发送的事件的时间长于 interval 时，master 才会发送心跳。

    将间隔设置为 0 将完全禁用心跳。interval 的默认值等于 slave_net_timeout 的值除以 2。

    将@@global.slave_net_timeout 设置为小于当前心跳间隔的值会导致发出警告。对心跳间隔发出 RESET SLAVE 的效果是将其重置为默认值。

    根据这些段落和slave_net_timeout的默认值（60 秒），I/O 线程似乎应该每 30 秒心跳一次。您可以像这样将心跳周期更改为 10 秒：

    STOP SLAVE;
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10;
START SLAVE;
    • 2

相关问题