mysql ab主从复制出错及解决过程

一、
mysql主从服务器报错描述：
Slave_IO_Running=NO，Slave_SQL_Running=YES，Last_Errno=0 mysql slave stop ; mysql slave start; mysql show slave status ; 如果Slave_IO_Running=YES ...
解决过程 ：
1 如果：Slave_IO_Running=NO，Slave_SQL_Running=YES，Last_Errno=0
mysql> slave stop ;
mysql> slave start;
mysql> show slave status ;
如果Slave_IO_Running=YES，Slave_SQL_Running=YES，Last_Errno=0
那么，数据库的replication已经成功启动。

2 如果提示有duplicated数据，直接delete那条数据之后的，然后
mysql> slave stop ;
mysql> slave start;
mysql> show slave status ;
如果Slave_IO_Running=YES，Slave_SQL_Running=YES，Last_Errno=0
那么，数据库的replication已经成功启动。

3 如果还不行，查看错误日志，看看是卡在那个binlog上了，比如 ： 卡在000079
则：
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000080', MASTER_LOG_POS=0;
SLAVE START;

4 如果错误提示： [mysql]Table tblName is marked as crashed and should be repaired
Mysql提示tblName表格已损坏，需要修复，解决方法：
进入到对应的数据库目录：
cd /var/lib/mysql/dbname
使用myisamchk修复：
shell> myisamchk -r tblName
如果提示failed
shell> myisamchk -f tblName
强制修复
恢复时间比较长，耐心等待修复完成
然后重启mysql就行 
二、
mysql主从服务器报错描述：
报警mysqla is down...机房人员反馈是HARDWARE ERROR（后面省略），让机房人员记下错误 信息，让他们帮忙重启，结果又正常工作了，（导出数据），过 了一会又出现报警，mysql_AB error。
解决过程 ：1、检查从库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''  on query. Default database: 'bug'. Query: 'insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)'
很显然，由于主库重启导致 从库数据不同步而且主键冲突。查看error 日志发现error日志文件变得好大，比以前大了将近好几倍，
tail -f mysql_error.log 最开始查看到的是这条信息
发现这条信息
 [ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,sta
te,mtime) values (443786,1007,0,-1,1262598003)', Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry '1007-443786-0' for key 'PRIMARY' Error_code: 1062
100104 17:39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'ufolog.000058
8' position 55793296
报错和上面的意思差不多,最先想到的就是首先手动同步一下，从库上首先 stop slave;停止同步
进入主库锁表，
FLUSH TABLES WITH READ LOCK；
mysql> show master status;
+-------------------+-----------+--------------+------------------+
| File              | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+-----------+--------------+------------------+
| ufo.000063 | 159164526 |              |                  |
+-------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)
进入从库
mysql>change master to master_host='192.168.1.141', master_user='slave',
master_password='xxx',
master_port=3306,
master_log_file='ufo.000063',
master_log_pos=159164526;

完成上面这些后
start slave;
回到主库
unlock tables; 解锁

回到从库 查看
show slave status \G;
发现正常了，长处了一口气。可是还没过一分钟，发现又开始报错了，还是最开始那个错误，再次查看一下日志，让我感到意外的是tail -f mysql_error.log 出现大量的
.......
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from `system_message_1` where `to_uid` = 181464 ORDER BY `id` ASC LIMIT 1
.........
日志里面有大量的这种警告，意思应该是statement 格式不安全，用vim 打开他看了一下，发现好多这类警告，我说为什么错误日志怎么变这么大了呢！！
statement format 应该是 binlog的一种格式，进入从库查看一下
show global variables like 'binlog_format';
果然当前的格式为statement

我需要把格式改为 mixed格式
修改从库的 my.cfg
在[mysqld]下面加入下面这行
binlog_format=mixed

然后重启mysql服务，发现错误日志里的 警告 都停止了。

三、
报错描述：
MySQL5.6之前的备库复制有两个工作线程：IO线程和SQL线程。SQL线程异常导致复制被中断。

许多DBA会遭受备库复制线程中断的报警，具体说来常见的错误有如下几类：

    1032错误 – HA_ERR_KEY_NOT_FOUND
    1062错误 – HA_ERR_FOUND_DUPP_KEY （HA_ERR_FOUND_DUPP_KEY 或 HA_ERR_FOUND_DUPP_UNIQUE）

问题背景：

主备数据一不致，往往是由于MySQL的Bug导致，其中MySQL复制相关的Bug从每次Release Notes都可以看到相关的身影，就我们最近两周线上遇到的列举如下：

    Table map set to 0 after altering MyISAM table （对InnoDB表也会触发）
    Failing assertion: trx->active_trans when renaming a table with active trx 
    Querying I_S.GLOBAL_TEMPORARY_TABLES or TEMPORARY_TABLES crashes threads working with temp tables（非DEBUG版本也存在）

当然，最大的一个未知的因素是主库宕机，甚至为保证服务可用而做的主备切换，有多少数据不一致，我们心里没有谱。只有依赖后续的定时扫描来做事后检测。虽然我们目前做的MHA从一定程度上回减少数据不一致的数量，但也无法做到数据严格一致。这个问题是MySQL社区的一大难题，在此不展开讨论。

另外，有发生异常时，DBA的不严格操作也可能会加剧这种数据不一致的影响，例如，遇到错误时，跳过若干错误，直到复制能正常工作。

    root@(none) 09:43:26>set global sql_slave_skip_counter=1;

解决思路：
对于我们线上最常见的两种类型进行智能化地处理，即 HA_ERR_KEY_NOT_FOUND 或 HA_ERR_FOUND_DUPP_KEY的错误，利用ROW模式复制的特点，在执行事件遇到错误时，进行如下转化：

    HA_ERR_KEY_NOT_FOUND：
         对于update事件 UPDATE_ROWS_EVENT 直接插入前镜像再做更新
        对于delete事件 DELETE_ROWS_EVENT 直接插入前镜像再做删除。
    HA_ERR_FOUND_DUPP_KEY：
        对于update事件 UPDATE_ROWS_EVENT先删除后镜像再更新
        对于insert事件 WRITE_ROWS_EVENT 直接以覆盖形式插入（即先删再插或转化成更新）。

新增变量及状态

对slave_exec_mode增加 SMART 模式(STRICT |　IDEMPOTENT | SMART)

    root@(none) 01:39:34>set global slave_exec_mode=SMART;
    Query OK, 0 rows affected (0.00 sec)

    root@(none) 01:39:39>select @@slave_exec_mode;
    +——————-+
    | @@slave_exec_mode |
    +——————-+
    | SMART |
    +——————-+
    1 row in set (0.00 sec)

增加对smart处理结果的统计：

    root@(none) 01:46:51>show status like ‘smart%’;
    +———————+——-+
    | Variable_name | Value |
    +———————+——-+
    | Smart_handle_dup_pk | 1 |
    | Smart_handle_failed | 0 |
    | Smart_handle_no_pk | 1 |
    +———————+——-+
    3 rows in set (0.00 sec)

 
运行情况：

从线上运行情况下，此patch解决了绝大部分复制中断异常，大大减少DBA半夜三更被警告吵醒手动修复异常复制的频率。总体而言，是一个非常成功的补丁。

但仍然存一此尚未完善的场景，例如唯一键约束或外键约束情况下，更新失败还是无法处理。在线上某个应用上，SMART还是不能处理unique key更新失败问题。
四、
slave日志中的错误代码1：
[ERROR] Error reading packet from server: Client requested master to start replication from impossible position; the last event was read from 'mysql-bin.000016' at 455562731, the last byte read was read from 'mysql-bin.000016' at 4. ( server_errno=1236) 
120725 23:19:17 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the last event was read from 'mysql-bin.000016' at 455562', Error_code: 1236

解决办法：
先查看主服务器中对应日志文件是否有此行，使用的命令是
mysqlbinlog  /YOURPATH/'mysql-bin.000016 >>/test
查找有没有455562对应的行 或者和这个数字很接近的行 然后使用chang master to 命令跳过这行，命令格式如下
stop slave;  
CHANGE MASTER TO MASTER_HOST='192.168.192.45',MASTER_USER='XXXX',MASTER_PASSWORD='XXXX',MASTER_LOG_FILE='mysql-bin.000016',MASTER_LOG_POS=455678;  
start slave;  
 
如果你找不到455562或者和这个数字很接近的行，你可以使用如下命令查看'mysql-bin.000016 的行数
ls -la mysql-bin.000016  
如果统计的行数远远少于455562，你可以跳过这个日志，从下一个日志开始复制，命令如下
stop slave;  
CHANGE MASTER TO MASTER_HOST='192.168.192.45',MASTER_USER='backup',MASTER_PASSWORD='weiphone',MASTER_LOG_FILE='mysql-bin.000017',MASTER_LOG_POS=4;  
start slave;

五、
错误类型代码2：
mysql slave Error_code: 1062  1054

解决过程 ：
如果日志中出现了这样代码，可能是错误的select，或update操作，master是跳过这些操作，但是被记录到了二进制日志中，slave会依据二进制中的语句做相同的动作，就会报错，知道原理了要做的操作就很简单了
stop slave;  
set gloable  sql_slave_skip_counter=n;    //n为你想跳过错误语句的个数  
start slave;  
如果你不想再遇到这种错误，可以写到slave配置文件中格式如下：
slave_skip_errors = 1062 
slave_skip_errors = all   //跳过所有类型的错误码

六、
错误提示：
mysql> start slave;
ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

[root@slave ~]# tail /var/log/mysqld.log
090105 11:53:52 [ERROR] Failed to open the relay log '/var/run/mysqld/mysqld-relay-bin.000013' (relay_log_pos 235)
090105 11:53:52 [ERROR] Could not find target log during relay log initialization
...

[root@slave mysql]# ls /var/run/mysqld/
mysqld-relay-bin.000001  mysqld-relay-bin.000003  mysqld-relay-bin.000005  mysqld-relay-bin.index   
mysqld-relay-bin.000002  mysqld-relay-bin.000004  mysqld-relay-bin.000006
[root@slave mysql]# cat master.info 
14
mysql-bin.000010
1235
192.168.3.21
slave
29019853
3307
60
0

[root@slave mysql]# cat relay-log.info 
/var/run/mysqld/mysqld-relay-bin.000013
235
mysql-bin.000010
1235

3

50703

解决过程：
[root@slave ~]# service mysqld stop
[root@slave mysql]# rm -fr master.info 
[root@slave mysql]# rm -fr relay-log.info
[root@slave ~]# grep skip-slave-start /etc/my.cnf
skip-slave-start
[root@slave ~]# service mysqld start
[root@master ~]# mysql -uroot -p
mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000011 |       98 |              |                  | 
+------------------+----------+--------------+------------------+
[root@slave ~]# mysql -uroot -p

mysql> change master to 
master_log_file='mysql-bin.000011',
master_log_pos=98,
master_host='192.168.3.21',
master_port=3307,
master_user='slave',
master_password='12345678';
Query OK, 0 rows affected (0.02 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.3.21
                Master_User: slave
                Master_Port: 3307
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000011
        Read_Master_Log_Pos: 98
             Relay_Log_File: mysqld-relay-bin.000002
              Relay_Log_Pos: 235
      Relay_Master_Log_File: mysql-bin.000011
           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: 98
            Relay_Log_Space: 235
            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

1 row in set (0.00 sec)

导致 mysql 主从复制出错的原因有很多修复的办法也很多，
希望遇到和这次一样问题的朋友看到这篇文章后会得到 一些启发和解决问题的方法。

标题：个人整理

 

http://hyrieshu.blog.51cto.com/6231736/1076731