MySQL 主从同步中断常见问题

Error_code: 1032 
【现象】 
  Last_Error: Could not execute Update_rows event on table kebao.t1; Can‘t find record in ‘t1‘, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event‘s master log mysql-bin.000014, end_log_pos 114166

  140719 23:01:04 [ERROR] Slave SQL: Could not execute Delete_rows event on table zhumh.t; Can‘t find record in ‘t‘, Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event‘s master log mysql-bin.000004, end_log_pos 2359, Error_code: 1032

【原因】 
  在主库为row或mixed模式下,从库数据不一致导致的SQL线程中断 
【解决】 
  1.到主库上查看event在执行什么更新,把数据查出来 
  2.到从库上看这条数据是否存在,修复。 
【如何避免】 
  1.可能导致主从不一致的SQL 
  2.不使用--binlog-ignore-db和--replicate-ignore-db 
  3.不适用trigger

Error_code: 1062

【现象】

  Last_Error: Query caused different errors on master and slave. Error on master: ‘Deadlock found when trying to get lock; try restarting transaction‘ (1213), Error on slave: ‘Duplicate entry ‘176484282‘ for key 1‘ (1062). Default database: ‘XXXXX‘. Query:   ‘INSERT INTO t1(id,cust_id,in_ucid,confrim_time) 
                SELECT csl.id,csl.cust_id,csl.in_ucid,csl.add_time 
                FROM tl_cust_stat_log csl, cust cust 
                WHERE csl.add_time >  NAME_CONST(‘stat_start_date‘,_utf8 0x323031342D30342D31392031373A33303A3030) AND csl.add_time <=  NAME_CONST(‘stat_end_date‘,_utf8 0x323031342D30342D32312031373A33303A3030) 
                AND (csl.cur_stat_2 = ‘0609‘ AND csl.opt_code = ‘CBSA‘) AND csl.cust_id = cust.id AND cust.posid =  NAME_CONST(‘posIdVar‘,34094)‘ 
【原因】 
  主库执行这条insert myISAM表 select from innodb表 对from的表加S锁,和另一个update语句死锁,导致这个insert..select被回滚。 
  但是insert 的myiSAM表没有被回滚,因此记入了binlog,在从库上执行导致duplicate key1062 
【解决办法】 
  1.确保更新语句中与从库一致 
    stop slave; 
    set global sql_slave_skip_counter=1; 
    start slave; 
  2.若不一致,则从库删掉相应数据,重新执行event。

    my.cnf 设置,一直后在修改 
    slave-skip-errors = 1062(用于修复主从)

Error_code: 1053

【现象】 
  140524  9:48:36 [ERROR] Slave: Error ‘Server shutdown in progress‘ on query. Default database: ‘crm_sale‘. Query: ‘load data INFILE ‘/home/mysql/mysql/tmp/SQL_LOAD-3367957599-1103609990-72.data‘ IGNORE INTO table XXX character set utf8‘,   Error_code: 1053

【原因】 
  mysql-5535,mysql-5615之前,都有这个bug,显式的kill查询时候会导致1053:server shutdown progress错误,并中断SQL线程。

【解决办法】 
  直接start slave;

Error_code: 1236

【现象】 
  Error: 1236 SQLSTATE: HY000 (ER_MASTER_FATAL_ERROR_READING_BINLOG) 
  Message: Got fatal error %d from master when reading data from binary log: ‘%s‘ 
【原因】 
  从库还未执行binlog,主库已经超过expire_log_days自动删除了binlog 
【处理】 
  1.若漏掉写入,则找到binlog备份,执行增量 
  2.若无写入,则重新change master到主库上第一个binlog的第一个点

Error_code: 1298

【现象】

  2014-12-31 07:25:01 32135 [Warning] Slave: Unknown or incorrect time zone: ‘UTC‘ Error_code: 1298 
  2014-12-31 07:30:31 32219 [ERROR] Slave SQL: Error ‘Unknown or incorrect time zone: ‘UTC‘‘ on query. Default database: ‘configuration‘. Query: ‘BEGIN‘, Error_code: 1298

【处理】 
  mysql_tzinfo_to_sql /usr/share/zoneinfo |  mysql  -uroot -proot1 -S /mysqldata/socket/mysql.sock_dsp3609 mysql

  --timezone  是mysqld_safe的参数

  [mysqld_safe] 
  timezone = GMT

  验证:

  SELECT @@global.time_zone, @@session.time_zone;

时间: 2024-11-01 16:01:26

MySQL 主从同步中断常见问题的相关文章

mysql主从同步(4)-同步延迟状态考量(seconds_behind_master和pt-heartbea)

一般情况下,我们是通过"show slave status \G;"提供的Seconds_Behind_Master值来衡量mysql主从同步的延迟情况.具体说明见:mysql主从同步(4)-Slave延迟状态监控,这种方法在大多数情况下确实是可行的.但是经验告诉我,仅仅依靠Seconds_Behind_Master的值来监测主从同步数据是否延迟是绝对不可靠的!!! 曾经遇到过的一个坑:Mysql主从环境部署后,刚开始主从数据同步是没问题的,也是通过监控Seconds_Behind_M

Mysql主从同步(复制)

目录: mysql主从同步定义      主从同步机制 配置主从同步      配置主服务器      配置从服务器 使用主从同步来备份      使用mysqldump来备份      备份原始文件 主从同步的小技巧 排错      Slave_IO_Running: NO      Slave_SQL_Running: No   mysql主从同步定义 主从同步使得数据可以从一个数据库服务器复制到其他服务器上,在复制数据时,一个服务器充当主服务器(master),其余的服务器充当从服务器(s

Mysql主从同步(Mysql A B复制)配置

Mysql主从同步(Mysql A B复制)配置 Mysql主从同步(Mysql AB复制)功能是自动备份数据 vim/var/lib/mysql/auto.cnf  数值不能一样 master主               slave从 192.168.1.1        192.168.1.2 1.主从环境配置:    mysql_5.6版本 servicemysql start         ping通         service iptablesstop         sete

mysql主从同步(3)-percona-toolkit工具(数据一致性监测、延迟监控)使用梳理

转自:http://www.cnblogs.com/kevingrace/p/6261091.html 在mysql工作中接触最多的就是mysql replication mysql在复制方面还是会有一些常规问题: 比如主库宕机或者从库宕机有可能会导致复制中断,通常需要进行人为修复, 或者很多时候需要把一个从库提升为主库,但对从库和主库的数据一致性不能保证一样. 这种情况下就需要使用percona-toolkit工具的pt-table-checksum组件来检查主从数据的一致性:如果发现不一致的

Mysql主从同步(复制)(转)

文章转自:https://www.cnblogs.com/kylinlin/p/5258719.html 目录: mysql主从同步定义 主从同步机制 配置主从同步 配置主服务器 配置从服务器 使用主从同步来备份 使用mysqldump来备份 备份原始文件 主从同步的小技巧 排错 Slave_IO_Running: NO Slave_SQL_Running: No mysql主从同步定义 主从同步使得数据可以从一个数据库服务器复制到其他服务器上,在复制数据时,一个服务器充当主服务器(master

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

前言 作为一名DBA,在工作中会经常遇到一些MySQL主从同步延迟的问题,这些同步慢的问题,其实原因非常多,可能是因为主从的网络问题导致,可能是因为网络带宽问题导致,可能是因为大事务导致,也可能是因为单线程复制导致的延迟. 今天遇到一个问题,Mysql持续报错,主从同步延时数过大或错误.所以这篇文章给大家分享下主从同步的机制原理以及问题排查思路. 故障表现 最直观的表现为: ? 1 2 3 4 5 6 7 mysql> show slave status\G;  // 状态一  Seconds_

MySQL主从同步延迟717秒?!!

原标题:MySQL主从同步延迟717秒?!! 最近业务MySQL主从监控刚加好,随后总收到延迟几百秒的告警,但实际排查下来却没有大碍,告警信息如下: 网上找下来也有人遇到同样的问题,(但这个问题属于MySQL的BUG还是zabbix的BUG呢?..) 分析的很有深度,原理透彻,这里分享给大家 MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是 今天碰到了一个场景,发现 Seconds_Behind_Ma

MYSQL 主从同步故障-Error1062--解决方案

MYSQL 主从同步故障-Error1062-解决方案 公司有两台Mysql服务器之前配置了主从同步,今天用户反映数据有差异,登陆到服务器上查看Mysql主从配置,发现有错误: show slave status \G;  果然出现问题了 Slave_IO_Running: Yes Slave_SQL_Running: No 而且出现了1062错误 Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY''

检查mysql主从同步结构中的从数据库服务器的状态-脚本shell

检查mysql主从同步结构(一主一从)中的从数据库服务器的状态          (ip授权.从服务器和IO是否正常.从mysql进程是否正常) 主mysql: 192.168.1.10 从mysql: 192.168.1.20 [[email protected] ~]# vi check_slave.sh #!/bin/bash master=192.168.1.10 i=1 service mysqld status &>/dev/null while [ true ] do echo