MySQL – 修复：从二进制日志读取数据时从主服务器收到致命错误 1236：日志事件条目超过 max_allowed_packet；增加master上的max_allowed_packet；

运维干货 7个月前导航君

87 0 0

如果你每天都花一整天的时间去维护数百台 MySQL 服务器，那么你很可能遇到过这个问题。如果您的服务器配置正确（即您在主服务器和从服务器上的配置相同），则很有可能该错误是虚假的，并不代表它所说的意思。那么为什么会发生呢？这还不完全清楚——这可能是硬件故障、网络层中的传输中数据损坏的结果（尽管在 TCP 校验和和 binlog 校验和之间，它几乎不可能通过而不被发现），或者真的很难重现 MySQL 错误（这种情况很少发生，我们在各种不同环境中的数百个数据库服务器上每年可能会看到 2-3 次）。

但它确实发生了。当它确实发生时，完全确保从站正常的唯一方法是重新初始化整个数据集——当你有数 TB 的数据时，这可能会很痛苦。当然，我们关注的大多数 MySQL 和 MariaDB 数据库服务器都在启用了每小时或每天快照的 ZFS 上运行。在这些情况下，我们可以简单地回滚到错误出现之前的最新快照，这几乎总能解决问题。但是那些没有基础设施的人

因此，让我们探讨一下您可以做什么来避免或至少推迟从站重新初始化。

通过实际示例工作

例如，如果它发生在您身上并且您在SHOW SLAVE STATUS\G输出中看到：

      Exec_Master_Log_Pos: 123516843
    Seconds_Behind_Master: NULL
            Last_IO_Errno: 1236
            Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.140409' at 123516843, the last event read from './mysql-bin.140409' at 123, the last byte read from './mysql-bin.140409' at 123516862.'

第一件看起来可疑的事情是，从 binlog 读取的位置和最后一个位置之间的差异Exec_Master_Log_Pos很小——因此极不可能在大小范围内max_allowed_packet transaction。

查看 master 上的 binlog，很快就会发现这两个 binlog 位置实际上是伪造的：

mysqlbinlog mysql-bin.140409 | grep '^# at ' | grep -P 'at 12351\d{4}$'
at 123512938 
at 123521149

所以我们也许可以通过重置从属复制坐标来逃脱惩罚：

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.140409', MASTER_LOG_POS=123512938, MASTER_HOST='master-server', MASTER_USER='master-user', MASTER_PASSWORD='master-password';

我们选择之前的值而不是之后的值的原因是因为在大多数情况下，如果有一个主键并且我们正在使用binlog_format=ROW，复制将在丢失的行（删除时）或重复键（INSERT 时）中断，我们可以跳过事务并恢复。如果我们在报告错误后直接获取第一个值，我们可能会错过一个事务，并且我们可能直到后来出现问题或直到我们可以检查时才知道pt-table-checksum——这可能需要数小时或数天的时间来处理数 TB 的数据。

来源：https://shatteredsilicon.net/fixing-error-1236-from-master-max_allowed_packet/

1236