转 -- MySQL主从失败, 错误Got fatal error 1236解决方法

本文介绍了一种解决MySQL主从复制过程中出现的致命错误1236的方法,通过调整复制位置和检查主服务器上的二进制日志来恢复正常的数据同步。

原址如下:

http://ritto.blog.51cto.com/427838/735810


MySQL主从失败, 错误Got fatal error 1236解决方法


由于主服务器异外重启, 导致从报错, 错误如下:

show slave status错误:

 
  1. mysql> show slave status\G 
  2. Master_Log_File: mysql-bin.000288 
  3. Read_Master_Log_Pos: 627806304 
  4. Relay_Log_File: mysql-relay-bin.000990 
  5. Relay_Log_Pos: 627806457 
  6. Relay_Master_Log_File: mysql-bin.000288 
  7. Slave_IO_Running: No 
  8. Slave_SQL_Running: Yes 
  9. Exec_Master_Log_Pos: 627806304 
  10. Relay_Log_Space: 627806663 
  11. ...... 
  12. Last_IO_Error: Got fatal error 1236 from master when  reading data from binary log: 
  13. 'Client requested master to start  replication from impossible position' 

mysql错误日志:

 
  1. tail /data/mysql/mysql-error.log 
  2. 111010 17:35:49 [ERROR] Error reading packet from server: Client requested master 
  3.  to start replication from impossible position ( server_errno=1236) 
  4. 111010 17:35:49 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data 
  5. from binary log: 'Client requested master to start replication from impossible 
  6. position', Error_code: 1236 
  7. 111010 17:35:49 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000288'
  8. position 627806304 

按照习惯, 先尝试必改position位置.

 
  1. mysql> stop slave; 
  2. mysql> change master to master_log_file='mysql-bin.000288',master_log_pos=627625751; 
  3. mysql> start slave; 

错误依旧, 接下来登陆到主服务器查看binlog日志.
先按照错误点的标记去主服务器日志中查找:

 
  1. [root@db1 ~]# mysqlbinlog --start-position=627655136 /data/mysql/binlog/mysql-bin.000288 
  2. /*!40019 SET @@session.max_insert_delayed_threads=0*/; 
  3. /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; 
  4. DELIMITER /*!*/; 
  5. at 4 
  6. #111010 13:31:19 server id 4 end_log_pos 106 Start: binlog v 4, server v 5.1.45-log 
  7. created 111010 13:31:19 
  8. # Warning: this binlog is either in use or was not closed properly. 
  9. BINLOG ' 
  10. F1aTTg8EAAAAZgAAAGoAAAABAAQANS4xLjQ1LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
  11. AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC 
  12. '/*!*/; 
  13. DELIMITER ; 
  14. End of log file 
  15. ROLLBACK /* added by mysqlbinlog */; 
  16. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; 

没有看到这个位置.

 
  1. [root@db1 ~]# mysqlbinlog /data/mysql/binlog/mysql-bin.000288 > test.txt 
  2.  
  3. less text.txt 
  4. 看最后一部分 
  5. at 627625495 
  6. #111010 16:35:46 server id 1 end_log_pos 627625631 Query thread_id=45613333 
  7. exec_time=32758 error_code=0 
  8. SET TIMESTAMP=1318289746/*!*/; 
  9. delete from freeshipping_bef_update where part='AR-4006WLM' and code='' 
  10. /*!*/; 
  11. at 627625631 
  12. #111010 16:35:46 server id 1 end_log_pos 627625751 Query thread_id=45613333 
  13. exec_time=32758 error_code=0 
  14. SET TIMESTAMP=1318289746/*!*/; 
  15. delete from shippingFee_special where part='AR-4006WLM' 
  16. /*!*/; 
  17. DELIMITER ; 
  18. End of log file 
  19. ROLLBACK /* added by mysqlbinlog */; 
  20. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; 

 

找到最接近错误标记627655136的一个position是627625631.

再回到slave机器上change master, 将postion指向这个位置.
 

 
  1. mysql> stop slave; 
  2. Query OK, 0 rows affected (0.00 sec) 
  3.  
  4. mysql> change master to master_log_file='mysql-bin.000288',master_log_pos=627625631; 
  5. Query OK, 0 rows affected (0.06 sec) 
  6.  
  7. mysql> start slave; 
  8. Query OK, 0 rows affected (0.00 sec) 

 

再次查看:

 
  1. mysql> show slave status\G 
  2. *************************** 1. row *************************** 
  3. Slave_IO_State: Queueing master event to the relay log 
  4. Master_Host: 192.168.21.105 
  5. Master_User: rep 
  6. Master_Port: 3306 
  7. Connect_Retry: 10 
  8. Master_Log_File: mysql-bin.000289 
  9. Read_Master_Log_Pos: 25433767 
  10. Relay_Log_File: mysql-relay-bin.000003 
  11. Relay_Log_Pos: 630 
  12. Relay_Master_Log_File: mysql-bin.000289 
  13. Slave_IO_Running: Yes 
  14. Slave_SQL_Running: Yes 

主从同步正常了, 同样的方法修复其它slave机器.

 

 

本文出自 “ritto's blog” 博客,请务必保留此出处http://ritto.blog.51cto.com/427838/735810






<think>我们面对的是MySQL主从复制中的致命错误1236,具体表现为从节点请求的GTID不在主节点的二进制日志中。这个问题通常发生在主库的二进制日志被清理或损坏,导致从库请求的GTID位置在主库的binlog中不存在。根据引用[2][3][4],我们得知这种错误与二进制日志位置或GTID的丢失有关。以下是系统的解决方案:###错误原因分析-**问题本质**:从库记录的GTID集合指向了主库已经清除或缺失的二进制日志位置(例如主库进行了日志清理或异常崩溃导致日志不连续)[^2][^4]。-**错误表现**:在`SHOWSLAVESTATUS`中会看到类似`Couldnotfindfirstlogfilenameinbinarylogindexfile`或`Gotfatalerror1236`的报错[^4]。###解决方案步骤####方法1:重建从库(推荐)当主库仍保留完整数据时,重建从库是最安全的方式:1.**主库备份**:```bashmysqldump--single-transaction--master-data=2--triggers--routines--all-databases-uroot-p>full_backup.sql```-`--single-transaction`:确保一致性快照(仅适用于InnoDB)[^3]-`--master-data=2`:记录备份时刻的二进制日志位置(以注释形式保存)2.**从库数据重置**:```sqlSTOPSLAVE;RESETSLAVEALL;--清除所有复制配置DROPDATABASEIFEXISTSyour_database;--根据实际情况选择是否删除数据```3.**导入备份**:```bashmysql-uroot-p<full_backup.sql```4.**重新配置复制**:-如果使用GTID模式(推荐):```sqlCHANGEMASTERTOMASTER_HOST='master_ip',MASTER_USER='repl_user',MASTER_PASSWORD='password',MASTER_AUTO_POSITION=1;STARTSLAVE;```-如果未启用GTID,使用备份文件中的位置信息:```sql--在备份文件中查找类似以下内容(通常在开头):--CHANGEMASTERTOMASTER_LOG_FILE='mysql-bin.00000X',MASTER_LOG_POS=XXX;CHANGEMASTERTO...--根据备份文件中的位置配置```####方法2:强制跳过错误位置(仅应急)>**警告**:此方法可能导致数据不一致,仅用于临时恢复服务,事后仍需重建从库[^2][^4]。1.停止从库复制:```sqlSTOPSLAVE;```2.获取主库当前有效GTID集合:```sql--在主库执行SHOWMASTERSTATUS;--记录Executed_Gtid_Set(例如:d2f4b52a-4d1a-11ee-bd7a-0242ac110001:1-1000)```3.在从库重置GTID位置:```sqlRESETMASTER;--清空从库本地的GTID执行记录(谨慎操作!)SET@@GLOBAL.GTID_PURGED='主库的Executed_Gtid_Set';--与主库完全一致[^3]```4.重新启动复制:```sqlCHANGEMASTERTOMASTER_AUTO_POSITION=1;STARTSLAVE;```###关键预防措施1.**延长二进制日志保存周期**修改主库配置(`my.cnf`):```ini[mysqld]expire_logs_days=7#至少保留7天日志```2.**启用复制延迟备份**建议配置延迟从库(延迟1-24小时),当主库误删日志时可从延迟库恢复:```sqlCHANGEMASTERTOMASTER_DELAY=3600;--延迟1小时```3.**定期监控GTID连续性**使用脚本检查主库的GTID连续性:```sqlSHOWGLOBALVARIABLESLIKE'gtid_executed';--应无间隔```###流程图:错误处理决策```mermaidgraphTDA[发生错误1236]-->B{主库是否仍存所需binlog?}B-->|是|C[尝试重建复制链路]B-->|否|D[检查备份可用性]D-->|有近期备份|E[用备份重建从库]D-->|无备份|F[强制重置从库GTID位置]F-->G[数据校验]-->H[确认业务影响]```>**重要提醒**:强制跳过错误位置后,务必使用`pt-table-checksum`进行数据校验[^2][^3]。若发现数据差异,需立即修复。§§相关问题§§1.如何配置MySQL的延迟复制?2.使用`pt-table-checksum`进行主从数据校验的具体操作步骤是什么?3.MySQL二进制日志管理的最佳实践有哪些?</think>### 解决MySQL主从复制错误1236(GTID不在主节点binlog) #### 错误原因分析 错误 `Got fatal error 1236` 并提示 **"GTID not in master binlog"** 通常由以下原因引起: 1. **主库二进制日志被清除**(最常见):主库的 `expire_logs_days` 设置导致所需GTID对应的binlog已被自动删除[^2][^4] 2. **主库异常断电**:导致binlog损坏或不连续[^2] 3. **从库GTID位置错误**:从库记录的GTID超出了主库当前binlog范围[^3] 4. **主库reset操作**:执行了 `RESET MASTER` 清空binlog[^4] --- ### 完整解决方案 #### 方法1:重建从库(推荐) 这是最安全可靠的解决方案,尤其当主库有完整数据时: ```bash # 1. 主库创建备份(使用GTID一致性参数) mysqldump --single-transaction --master-data=2 --set-gtid-purged=ON -u root -p --all-databases > full_backup.sql # 2. 从库停止复制并重置 mysql -u root -p -e "STOP SLAVE; RESET SLAVE ALL;" # 3. 导入备份到从库 mysql -u root -p < full_backup.sql # 4. 重新配置复制(GTID模式) mysql -u root -p -e " CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='repl_user', MASTER_PASSWORD='your_password', MASTER_AUTO_POSITION=1; START SLAVE; " ``` #### 方法2:强制同步GTID位置(应急方案) > ⚠️ 仅用于临时恢复服务,可能导致数据不一致[^3] ```sql -- 在从库执行 STOP SLAVE; -- 获取主库当前GTID集合 -- 在主库执行:SHOW MASTER STATUS\G -- 记录 Executed_Gtid_Set 值 (例: 3a9b150a-8a44-11ee-bd7a-00155d016201:1-1000) -- 在从库重置GTID RESET MASTER; SET @@GLOBAL.GTID_PURGED = '3a9b150a-8a44-11ee-bd7a-00155d016201:1-1000'; -- 重新启动复制 CHANGE MASTER TO MASTER_AUTO_POSITION=1; START SLAVE; ``` #### 方法3:跳过缺失的GTID(高风险) ```sql -- 在从库执行 STOP SLAVE; SET GTID_NEXT='3a9b150a-8a44-11ee-bd7a-00155d016201:1001'; -- 替换为缺失的GTID BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE; ``` --- ### 关键预防措施 1. **延长binlog保存时间** 修改主库配置 `/etc/my.cnf`: ```ini [mysqld] expire_logs_days = 7 # 至少保留7天日志 ``` 2. **定期备份binlog** 使用脚本定期备份binlog到安全存储: ```bash # 每天备份binlog rsync -av /var/lib/mysql/mysql-bin.* backup-server:/mysql-binlog-backup/ ``` 3. **启用复制监控** 配置告警规则: ```sql SHOW SLAVE STATUS WHERE Slave_IO_Running != 'Yes' OR Slave_SQL_Running != 'Yes' OR Seconds_Behind_Master > 60; ``` 4. **使用延迟从库** 配置一个延迟1小时的从库作为保险: ```sql CHANGE MASTER TO MASTER_DELAY = 3600; ``` --- ### 数据一致性验证 修复后必须进行数据校验: ```bash # 使用Percona Toolkit检查 pt-table-checksum --host=master_ip --user=check_user --password=pass --databases=your_db # 修复差异(谨慎使用) pt-table-sync --execute --sync-to-master h=slave_ip,D=your_db,t=your_table ``` > **重要提示**:方法2和3可能导致数据丢失,修复后应立即使用 `pt-table-checksum` 校验数据一致性[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值