应用过大的MySQL二进制日志（binlog）恢复数据时的问题咨询

嘿，这个大binlog恢复的问题确实挺棘手的，我来给你梳理几个靠谱的解决办法：

一、最简单的方案：临时调大max_allowed_packet参数 #

其实你不用费劲拆分binlog，只要临时把max_allowed_packet调得比你的2.4G binlog大就行，恢复完再改回去就好：

1. 登录MySQL终端，执行这条命令（设置成3G足够覆盖你的2.4G文件）：

   SET GLOBAL max_allowed_packet = 3*1024*1024*1024;
   

2. 退出当前MySQL连接，重新登录（因为全局参数修改后需要新会话才能生效）。
3. 直接用mysqlbinlog导入整个大binlog：

   mysqlbinlog your_large_binlog_file | mysql -u your_username -p
   

这个方法最省心，只要你的服务器内存能支撑临时的大参数就行，不会有长期影响。

二、如果必须拆分binlog：按完整事件边界分段导出 #

用split命令拆分肯定不行，因为binlog是带特定结构的二进制文件，硬拆会破坏事件完整性，导致“bad magic number”错误。咱们得用mysqlbinlog本身的能力，按完整语句/事件边界来分段：

1. 先列出binlog里所有事件的详细位置信息，执行：

   mysqlbinlog --show-events your_binlog_file > binlog_events.txt
   

   这个文件里会显示每个事件的Pos（起始位置）、End_log_pos（结束位置）和事件类型，比如Query事件就是完整的SQL语句。
2. 从binlog_events.txt里挑选合适的分段点，确保每个分段的--stop-position对应某个事件的End_log_pos（也就是完整语句的结束位置），比如你之前遇到的情况，应该用199994536作为stop-position，而不是200000003。
3. 循环导出每个分段，比如：

   # 第一段：从起始位置4到第一个分段结束位置199994536
   mysqlbinlog --start-position=4 --stop-position=199994536 your_binlog_file > segment1.sql
   # 第二段：从上一段的结束位置开始，到下一个完整事件结束位置
   mysqlbinlog --start-position=199994536 --stop-position=xxxxxx your_binlog_file > segment2.sql
   

   注意：下一段的--start-position就是上一段的End_log_pos，因为下一个事件刚好从这个位置开始。
4. 逐个导入这些分段文件：

   mysql -u your_username -p < segment1.sql
   mysql -u your_username -p < segment2.sql
   

这样导出的每个分段都是完整的事件/语句，就不会出现你之前碰到的“partial statement”警告了。

三、额外提醒 #

• 恢复前一定要先备份当前的数据库，避免操作失误导致数据丢失。
• 如果你的binlog是GTID模式的，记得在导入时加上--skip-gtids参数（如果是从备份恢复后应用binlog，确保GTID不会冲突）。

备注：内容来源于stack exchange，提问作者MaKR