18-从库复制出错的处理

mysql> select * from repl_test;

上文提到过，在某些情况下，会出现从库更新失败，这时，首先需要确定是否是从库的表与主库的不同造成的。如果是表结构不同导致的，则修改从库的表使之与主库的相同，然后重新运行START SLAVE语句。

如果不是表结构不同导致的更新失败，则需要确认手动更新是否安全，然后忽视来自主库的更新失败的语句。跳过来自主库的语句的命令为 SET GLOBAL SQLSLAVE SKIP_COUNTER = n，其中 n的取值为 1或者 2。如果来自主库的更新语句不使用 AUTO_INCREMENT 或 LAST_INSERT_ID()，n 值应为 1，否则，值应为 2。原因是使用 AUTO_INCREMENT或LAST_INSERT_ID()的语句需要从二进制日志中取两个事件。以下例子就是在从库端模拟跳过主库的两个更新语句的效果。

（1）首先，在从库端先停止复制进程，并设置跳过两个语句：

mysql> select * from repl_test;

+------+

| id |

+------+

| 1 |

+------+

1 row in set (0.00 sec)

mysql> stop slave;

Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL SQL_slave_SKIP_COUNTER = 2;

Query OK, 0 rows affected (0.01 sec)

（2）在主库端插入3条记录：

mysql> select * from repl_test;

+------+

| id |

+------+

| 1|

+------+

1 row in set (0.00 sec)

mysql> insert into repl_test values(2);

Query OK, 1 row affected (0.00 sec)

mysql> insert into repl_test values(3);

Query OK, 1 row affected (0.00 sec)

mysql> insert into repl_test values(4);

Query OK, 1 row affected (0.00 sec)

mysql> select * from repl_test;

+------+

| id |

+------+

| 1|

| 2|

| 3|

| 4|

+------+

4 rows in set (0.00 sec)

（3）从库端启动复制进程，检查测试的表，发现首先插入的两条记录被跳过了，只执行了第3条插入语句：

mysql> start slave;

Query OK, 0 rows affected (0.00 sec)

+------+

| id |

+------+

| 1 |

| 4 |

+------+

2 rows in set (0.00 sec)