.版本
1)操作系统
cat /etc/issue
CentOS release 6.9 (Final)
Kernel \r on an \m
cat /proc/version
Linux version 2.6.32-696.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) ) #1 SMP Tue Mar 21 19:29:05 UTC 2017
2)mysql数据库版本
mysql --version
mysql Ver 14.14 Distrib 5.6.26, for linux-glibc2.5 (x86_64) using EditLine wrapper
2. 问题描述
2.1 发现问题
我们知道，MySQL 5.6 针对复制功能提供了新特性: slave支持crash-safe. 该功能可以解决之前版本中系统异常断电可能导致的SQL thread 信息不准确的问题。##关于crash-safe 详细介绍请参见 MySQL5.6新特性之crash-safe slaves
crash-safe的大概原理就是把sql thread 的执行位置记录到表中(innodb表)，并且把 sql thread 线程执行事务和更新mysql.slave_replay_log_info的语句看成一个事务处理，从而避免实际已执行的binlog位点和写入relay log info 的位点信息不一致的情况发生。 但是在测试crash-safe 功能时发现了点问题，如果我指定了 relay_log_info_repository = TABLE,这时主库执行DDL语句后，从库的 relay_log_info_repository 表中的 Master_log_pos 字段并不会立即被更新(这时ddl操作已经被应用到从库，并且从库show slave status\G; 查看执行的位置是正确的)，而DML语句不会有该问题。
##这时有两种情况会让从库的 relay_log_info_repository表信息更新到最新值
1)如果此时主库再执行一个dml操作，我们会发现从库 relay_log_info_repository 中记录的位置被更新为最新值。
2)重启复制线程 stop slave; start slave;
如果在主库执行了一个ddl，并且该ddl被从库应用后，紧接着从库异常宕机。那么从库再启动后可能会把之前已经执行过的ddl再次执行一遍，导致复制异常 会遇到如下错误：
Error 'Duplicate column name 'name_1'' on query. Default database: 'test_shao'. Query: 'alter table test_4 add column name_1 varchar(20)'
##我在测试环境主库添加字段后，从库应用该ddl后，杀掉从库，然后再重启遇到的错误，数据库 relay_log_info_repository = TABLE，sync_relay_log_info = 10000。
如果你清楚的知道你的主从复制是由上面说的原因导致的问题，可以通过 set global sql_slave_skip_counter=1; 跳过该错误，修复主库复制