MySQL 主二进制日志损坏

Question

我们最近对我们的基础设施进行了一些更改，现在我无法保持 MySQL 复制运行。奴隶抱怨二进制日志损坏，重置它无济于事。我一直在我的主日志中看到这样的条目：

二进制日志'
WFxKTRNJAAAAPwAAAKY/YwAAABsAAAAAAAEACHdlYmVkaTMwAA1QYXJ0bmVyQ29uZmlnAAQICA8P
BC0AYwAA
WFxKTRhJAAAAXAAAAAAJAYwAAABsAAAAAAAEABP//8BoSAAAAAAAAAAggMAAAAAAAAJUEFDS0NPVU5U
Azc3MfAaEgAAAAAAAIIDAAAAAAAACVBBQ0tDT1VOVAM3NzI=
'/*!*/;

在从属日志中，这只是作为“未知事件”出现，并且复制在该位置失败。

这是我给主人的 my.cnf：

[mysqld]
datadir=/data/mysql-data
套接字=/tmp/mysql.sock
用户=mysql
日志错误=/var/log/mysqld.log

binlog-do-db = db1
binlog-do-db = db2
binlog-do-db = db3
binlog-do-db = db4
binlog_format = '混合'

log-bin = /data/mysql-binlogs/mysql-bin.log
服务器 ID=73
报告主机=thisserver.mydomain.com

线程缓存大小 = 30
key_buffer_size = 700M
myisam_sort_buffer_size = 300M
table_cache = 256
sort_buffer_size = 4M
read_buffer_size = 1M
innodb_data_home_dir = /data/mysql-data/
innodb_data_file_path = InnoDB:100M:autoextend
设置变量 = innodb_buffer_pool_size=500M
设置变量 = innodb_additional_mem_pool_size=10M
设置变量 = max_connections=500
innodb_log_group_home_dir = /data/mysql-data
设置变量 = innodb_log_file_size=20M
设置变量 = innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit = 1

有谁知道是什么导致了我的主二进制日志中的乱码？

Answer 1

令人惊讶的是，这不是胡言乱语。

每当您对使用 MySQL 5.1 和 MySQL 5.5 生成的二进制日志执行 mysqlbinlog 时，这确实会出现在二进制日志的顶部。你不会在 MySQL 5.0 和后面的二进制日志中看到那些乱码。

这就是为什么从空二进制日志复制的起点是

• 107 为 MySQL 5.5
• 106 为 MySQL 5.1
• MySQL 5.0 及以后版本为 98

如果您在 MySQL 5.1 和从站为 MySQL 5.0 的情况下进行 MySQL 复制，请记住这一点。这可能会让人非常头疼。

从使用 5.0 的 Master 和使用 5.1 的 Slave 复制工作正常，而不是相反。（根据 MySQL 文档，通常不支持它的原因有 3 个：1）二进制日志格式，2）基于行的复制，3）SQL 不兼容）。

无论如何，在master上的违规二进制日志上做一个mysqlbinlog。如果结果转储在转储中间产生乱码（我在 DBA 职业生涯中见过几次），您可能必须跳到位置 98 (MySQL 5.0) 或 106 (MySQL 5.1) 或 107 (MySQL 5.5)主的下一个二进制日志并从那里开始复制（SOB :(你可能需要使用 MAATKIT 工具 mk-table-checksum 和 mk-table-sync 来重新加载主更改而不是在从服务器上[如果你想成为英雄] ; 更糟糕的是，mysqldump master 并重新加载 slave 并完全重新开始复制​​ [如果你不想成为英雄]）

如果在您看到的顶级乱码之后，master 的 mysqlbinlog 是完全可读的，则可能 master 的二进制日志很好，但从站上的中继日志已损坏（由于传输/CRC 错误）。如果是这种情况，只需通过发出 CHANGE MASTER TO 命令重新加载中继日志，如下所示：

STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='< master-host ip or DNS >',
MASTER_PORT=3306,
MASTER_USER='< usernmae >',
MASTER_PASSWORD='< password >',
MASTER_LOG_FILE='< MMMM >',
MASTER_LOG_POS=< PPPP >;
START SLAVE;

在哪里

• MMMM 是 Master 使用的最后一个文件，最后在 Slave 上处理
• PPPP 是最后一次在 Slave 上处理的 Master 使用的最后一个位置

你可以通过做SHOW SLAVE STATUS\G和使用来获得 MMMM 和 PPPP

• MMMM 的 Relay_Master_Log_File
• PPPP 的 Exec_Master_Log_Pos

试试看，让我知道！！！

顺便说一句，运行 CHANGE MASTER TO 命令会擦除从站的当前中继日志并重新开始。