`
wenson
  • 浏览: 1052136 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论

mysql主从同步报错故障处理总结 [数据库技术]

 
阅读更多

 前言

在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,
如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法。

生产环境架构图
目前现网的架构,保存着两份数据,通过异步复制做的高可用集群,两台机器提供对外服务。在发生故障时,切换到slave上,并将其变成
master,坏掉的机器反向同步新的master,在处理故障时,遇到最多的就是主从报错。下面是我收录下来的报错信息。

常见错误
最常见的3种情况
这3种情况是在HA切换时,由于是异步复制,且sync_binlog=0,会造成一小部分binlog没接收完导致同步报错。

第一种:在master上删除一条记录,而slave上找不到。
Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1; 
Can't find record in 't1', 
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; 
the event's master log mysql-bin.000006, end_log_pos 254

第二种:主键重复。在slave已经有该记录,又在master上插入了同一条记录。
Last_SQL_Error: Could not execute Write_rows event on table hcy.t1; 
Duplicate entry '2' for key 'PRIMARY', 
Error_code: 1062; 
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924

第三种:在master上更新一条记录,而slave上找不到,丢失了数据。
Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1', 
Error_code: 1032; 
handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263
异步半同步区别
异步复制
简单的说就是master把binlog发送过去,不管slave是否接收完,也不管是否执行完,这一动作就结束了.

半同步复制
简单的说就是master把binlog发送过去,slave确认接收完,但不管它是否执行完,给master一个信号我这边收
到了,这一动作就结束了。(谷歌写的代码,5.5上正式应用。)

异步的劣势
当master上写操作繁忙时,当前POS点例如是10,而slave上IO_THREAD线程接收过来的是3,此时master宕机
,会造成相差7个点未传送到slave上而数据丢失。

特殊的情况
slave的中继日志relay-bin损坏。
Last_SQL_Error: Error initializing relay log position: I/O error reading the header from the binary log
Last_SQL_Error: Error initializing relay log position: Binlog has bad magic number; 
It's not a binary log file that can be used by this version of MySQL
这种情况SLAVE在宕机,或者非法关机,例如电源故障、主板烧了等,造成中继日志损坏,同步停掉。

人为失误需谨慎:多台slave存在重复server-id
这种情况同步会一直延时,永远也同步不完,error错误日志里一直出现上面两行信息。解决方法就是把server-id改成不一致即可。

Slave: received end packet from server, apparent master shutdown:
Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000012' at postion 106
问题处理
删除失败
在master上删除一条记录,而slave上找不到。

Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1; 
Can't find record in 't1',
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; 
the event's master log mysql-bin.000006, end_log_pos 254
解决方法:

由于master要删除一条记录,而slave上找不到故报错,这种情况主上都将其删除了,那么从机可以直接跳过。可用命令:

stop slave;
set global sql_slave_skip_counter=1;
start slave;
如果这种情况很多,可用我写的一个脚本skip_error_replcation.sh,默认跳过10个错误(只针对这种情况才跳,其他情况输出错误结果,等待处理),
这个脚本是参考maakit工具包的mk-slave-restart原理用shell写的,功能上定义了一些自己的东西,不是无论什么错误都一律跳过。)

主键重复
在slave已经有该记录,又在master上插入了同一条记录。

Last_SQL_Error: Could not execute Write_rows event on table hcy.t1; 
Duplicate entry '2' for key 'PRIMARY', 
Error_code: 1062; 
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924
解决方法:

在slave上用desc hcy.t1; 先看下表结构:

mysql> desc hcy.t1;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | NO   | PRI | 0       |       | 
| name  | char(4) | YES  |     | NULL    |       | 
+-------+---------+------+-----+---------+-------+
删除重复的主键

mysql> delete from t1 where id=2;
Query OK, 1 row affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
……
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
mysql> select * from t1 where id=2;
在master上和slave上再分别确认一下。

更新丢失
在master上更新一条记录,而slave上找不到,丢失了数据。

Last_SQL_Error: Could not execute Update_rows event on table hcy.t1; 
Can't find record in 't1', 
Error_code: 1032; 
handler error HA_ERR_KEY_NOT_FOUND; 
the event's master log mysql-bin.000010, end_log_pos 794
解决方法:

在master上,用mysqlbinlog 分析下出错的binlog日志在干什么。

/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000010 | grep -A '10' 794

#120302 12:08:36 server id 22  end_log_pos 794  Update_rows: table id 33 flags: STMT_END_F
### UPDATE hcy.t1
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='bbc' /* STRING(4) meta=65028 nullable=1 is_null=0 */
### SET
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='BTV' /* STRING(4) meta=65028 nullable=1 is_null=0 */
# at 794
#120302 12:08:36 server id 22  end_log_pos 821  Xid = 60
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
在slave上,查找下更新后的那条记录,应该是不存在的。

mysql> select * from t1 where id=2;
Empty set (0.00 sec)
然后再到master查看

mysql> select * from t1 where id=2;
+----+------+
| id | name |
+----+------+
|  2 | BTV  | 
+----+------+
1 row in set (0.00 sec)
把丢失的数据在slave上填补,然后跳过报错即可。

mysql> insert into t1 values (2,'BTV');
Query OK, 1 row affected (0.00 sec)

mysql> select * from t1 where id=2;    
+----+------+
| id | name |
+----+------+
|  2 | BTV  | 
+----+------+
1 row in set (0.00 sec)

mysql> stop slave ;set global sql_slave_skip_counter=1;start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
……
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
……
中继日志损坏
slave的中继日志relay-bin损坏。

Last_SQL_Error: Error initializing relay log position: I/O error reading the header from the binary log
Last_SQL_Error: Error initializing relay log position: Binlog has bad magic number;  
It's not a binary log file that can be used by  this version of MySQL

手工修复
解决方法:找到同步的binlog和POS点,然后重新做同步,这样就可以有新的中继日值了。

例子:

mysql> show slave status\G;
*************************** 1. row ***************************
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 1191
               Relay_Log_File: vm02-relay-bin.000005
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1593
                   Last_Error: Error initializing relay log position: I/O error reading the header from the binary log
                 Skip_Counter: 1
          Exec_Master_Log_Pos: 821

Slave_IO_Running :接收master的binlog信息
                   Master_Log_File
                   Read_Master_Log_Pos

Slave_SQL_Running:执行写操作
                   Relay_Master_Log_File
                   Exec_Master_Log_Pos

以执行写的binlog和POS点为准。

Relay_Master_Log_File: mysql-bin.000010
Exec_Master_Log_Pos: 821
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=821;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.8.22
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 1191
               Relay_Log_File: vm02-relay-bin.000002
                Relay_Log_Pos: 623
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1191
              Relay_Log_Space: 778
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 

转自:http://hcymysql.blog.51cto.com/5223301/888007

 

 

分享到:
评论

相关推荐

    线上MYSQL同步报错故障处理方法总结(必看篇)

    在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法。...

    MySQL主从同步机制与同步延时问题追查过程

    作为一名DBA,在工作中会经常遇到一些MySQL主从同步延迟的问题,这些同步慢的问题,其实原因非常多,可能是因为主从的网络问题导致,可能是因为网络带宽问题导致,可能是因为大事务导致,也可能是因为单线程复制导致...

    MySQL主从同步中的server-id示例详解

    MySQL主从同步是构建高可用性和容灾恢复的常见手段,确保数据在多个数据库实例间的一致性。在这个过程中,`server-id` 和 `server-uuid` 是两个至关重要的配置参数,它们对于复制过程的正常运行起到关键作用。 **...

    Mysql 5.6.26 主从搭建完整版.pdf

    文章内容涉及环境配置、MySQL安装、配置文件修改、主从同步设置等多个方面,为读者提供一个完整搭建MySQL主从架构的过程。 首先,我们来了解环境配置部分。文章明确指出,所使用的操作系统版本为CentOS 7.6,MySQL...

    MySQL数据库InnoDB引擎主从复制同步经验总结

    MySQL数据库的InnoDB引擎主从复制是一个常见的高可用性和数据冗余策略,它允许数据在多个服务器之间异步同步,确保即使主服务器故障,从服务器也能接管服务,保证业务连续性。以下是对主从复制的一些关键知识点的...

    mysql5.6-5.5主从备份

    MySQL主从备份是一种常见的数据冗余和高可用性解决方案,它允许数据在多个服务器之间同步,确保即使主服务器出现故障,从服务器也能接管并继续提供服务。在这个场景中,我们有两台服务器:A服务器作为主服务器运行...

    InnoDB引擎数据库主从复制同步新的分享

    MySQL主从同步是数据库高可用性的一种常见实现方式,它能够保证数据在多个服务器之间的复制,提高数据的容灾能力和读写性能。在本文中,我们将探讨InnoDB引擎下的主从复制特性以及相关注意事项。 1. 异步复制机制:...

    云计算项目(三阶段)1

    1. **MySQL主从同步**: - **工作过程**:主服务器上的更改记录在二进制日志中,从服务器通过I/O线程读取并应用这些日志,SQL线程则负责执行实际的更新。 - **主服务器配置**:开启二进制日志,设置服务器ID,开放...

    一次 MySQL 误操作导致的事故,「高可用」都顶不住了!.doc

    2. 但即使目录创建成功,MySQL在启动时仍报错,提示找不到首个binlog文件名,导致从库的I/O线程无法正常运行。 六、恢复过程 在解决上述问题后,发现新的问题——从库的I/O线程没有运行,且无法找到主库的binlog...

    MySQL管理之道 性能调优、高可用与监控.part2.rar

    第4章 同步复制报错故障处理 112 4.1 最常见的3种故障 112 4.1.1 在master上删除一条记录时出现的故障 112 4.1.2 主键重复 114 4.1.3 在master上更新一条记录,而slave上却找不到 115 4.2 特殊情况:slave的...

    MySQL运维-应急处理手册

    通过本手册的学习,运维人员能够更好地掌握MySQL主从复制的监控与故障处理流程,提升数据库系统的稳定性和可靠性。此外,对于可能出现的各种异常情况,也提供了详细的处理方案,有助于运维团队快速响应,减少业务...

    Mysql 1864 主从错误解决方法

    MySQL 1864错误是主从复制架构中常见的一个问题,通常与多线程复制功能有关。当从库尝试从主库同步数据时,会因为某些配置不当...通过本文的讲解,读者能够更加从容地应对MySQL 1864主从错误,保证数据库的稳定运行。

    canal.deployer-1.0.24

    Canal是阿里巴巴开源的基于MySQL协议的数据库增量日志订阅与消费组件,主要用于数据库的实时备份、数据同步、数据迁移等场景。它能够监听MySQL的数据变更事件,并将这些变更实时地推送给订阅者。Canal支持多种协议,...

    mysql5.7.22的libmysql.dll和libmysql.lib

    5. **复制改进**:提高了复制的稳定性和效率,添加了GTID(全局事务标识符)以简化主从复制的管理和故障恢复。 6. **存储过程和触发器的改进**:增加了对存储过程和触发器的调试支持,提高了开发者的工作效率。 7....

    爷青回,canal 1.1.6来了,几个重要特性和bug修复.doc

    GTID 是 MySQL 5.6 引入的全局事务标识,简化了主从复制的搭建和故障切换,修复此问题使得基于 GTID 的数据同步更加稳定。 - **RDB 同步关键字报错**:1.1.6 版本修复了因特定关键字引起的数据同步错误,提高了同步...

Global site tag (gtag.js) - Google Analytics