现在不少公司都在用MySQL（master）-->MySQL（slave）的框架，当然也有一主多从的架构，这也是MySQL主从的一个延伸架构;当然也有的公司MySQL主主的架构，MySQL主主架构要是处理得不适当，会面临各种各样的问题，当然啦，每种数据库构架都有自己的优缺点，合适自己公司业务需求的且方便自己维护的架构都可以认为是理想的构架，当出现同步断开了，我们是不是一味的使用--slave-skip-errors=[error_code]来跳过错误代码呢？其实不是的，这样做可能会造成数据不一致的可能，下面我只针对MySQL Replication常见的错误进行说明及处理。

一、在master上更新一条记录时出现的故障（master与slave处理同步的情况下，binlog为row格式）

在slave库上，模拟slave少了一条数据，所以把id=6的记录在slave上先delete掉：

然后在master上更新id为6的记录：

回slave库看下同步状态是否正常：

可以看到，同步已经断开，根据slave的报错信息去查看master的binlog到底做了什么，从上面看现在master做的操作写的binlog是mysql-bin.000004，end_log_pos=3704

可以看到做了更新的操作UPDATE xuanzhi.test where id=6的操作，我们在slave库上查看id为6的记录:

可以看到slave库上并没存在这样的记录。我们回到master查看下id=6的记录：

下面我们要解决同步问题呢？操作如下：把丢失的数据补到slave上：

正常同步了。如果有N多数据缺失，得用pt-table-checksum校验数据一致性，很多同学会好奇为什么slave库上会少数据呢？我总结了以下几种情况，当然还有别的：

1、当人为设置set session sql_log_bin=0时，当前session操作是不记录到Binlog的。

2、就是slave没设置为read only，在slave库上有删除操作

3、slave读取master的binlog日志后，需要落地3个文件：relay log、relay log info、master info，这三个文件如果不及时落地，则主机crash后会导致数据的不一致

二、估计比较常见的一种错误，就是错误代码为1062的错误，主键冲突

在slave上添加一条记录，模拟slave上还存在旧的数据记录，此时master是没有的这条记录的（这里的id自增主键）

在master上操作，添加一条id为5的记录：

回到slave库查看同步状态：

可以看到提示1062主键冲突错误，在表xuanzhi.test上，那么，此时我们应该考虑以谁的数据为准？我们当然要以master库的数据为准啦，所以我们需要把slave上主键为5的记录给删除掉，删除前要先desc查看表结构确定自增主键在什么列：

嘻嘻，有人会想，如果有N多主键冲突，这样手动清除冲突的记录有点不科学，是的，所以我写了写脚本去清除，可以参考我写的主从复制1062错误的解决方法。有人会好其，这样删除后，启动同步线程，记录还会不会同步过来呢，答案是会的

可以看到主键值为5的记录被同步过来了。当备库在一次非计划的关闭后重启时，会去读master.info文件以找到上次停止复制的位置。不幸的是，该文件可能并没有同步写到磁盘，因为该信息是在缓存中，可能并没有刷新到磁盘文件master.info。文件中存储的信息可能是错误的，备库可能会尝试重新执行一些二进制日志事件，这可能导致主键冲突，就是我们常常看见的1062错误。除非能确定备库在哪里停止（很难），否则唯一的办法就是忽略那些错误。

三、master上删除一条记录时出现的故障。

在master上删除一条记录，但这条记录在slave库上并不存在的时候，同步会不会断开，下面我们瞧瞧看：

在slave上delete一条数据，模拟slave比master少了数据：

在master上进行dalete行记录的操作，此时的slave是不存在这条记录了的：

回到slave库查看下状态，同步已经断开：

我们分析错误信息可以看到关键字是Delete_rows，这样处理就很简单了，因为master库是删除数据操作，所以slave库上没这条数据也没关系，所以在slave库上跳过此错误即可（当出现这种情况，就应该引起注意了，应该去检查是否还有更多的数据丢失了）

可以看到同步正常了。你在master上delete一条master都没有记录，同步是不会断开的。

四、slave的中继日志relay-log损坏

现在模拟slave库down机，relay-log损坏了，同步无法正常：

断电后启动slave库后，执行slave start后查看状态会报日志读不了或者损坏（有时直接断电slave并不一定损坏或者掉数据，如果配置参数合理的话）：

show slave status几个重要参数说明：

Slave_IO_Running: 接收master的binlog信息

Master_Log_File： 正在云读取master上binlog日志名

Read_master_Log_Pos: 正在读取master上当前的binlog日志POS点

slave_SQL_Running: 执行写操作。

Relay_master_Log_File： 正在同步master上binlog日志名

Exec_master_log_Pos: 正在同步当前binlog日志的POS点

 出现relay log损坏的话，以 Relay_master_Log_File 和 Exec_master_Log_Pos参数值为基准，从上面看到Relay_master_Log_File：mysql-bin.000004 、Exec_master_Log_Pos=590788350，这时我们需要做的就是change master操作：

这样会导致丢弃所有在磁盘上的中继日志。 

如果出现以下的报错，也是按以上的方法解决：

 通过这种方法去修改中继日志，是不是发现有些麻烦呢？其实MySQL5.5已经考虑到slave宕机中继日志损坏这一问题了，即在slave的配置文件my.cnf里要增加一个参数relay_log_recovery=1就可以了。

总结：

   一、遇到同步断开时，不能一味的使用--slave-skip-errors=[error_code]来跳过错误代码，这样很容易导致数据不一致的发生

   二、binlog为STATEMENT格式时，在mater进行更新或者删除一条slave库没有的数据，同步是不会断开的。

   三、定期检查数据的完整性，可以用pt-table-checksum校验主从数据的一致性，数据的完整性，对一个公司来说，无疑是最重要的。

   四、slave库上建议把一些重要的选项开启，例如设置为read only、relay_log_recovery、sync_master_info、sync_relay_log_info、sync_relay_log这些重要选项开启。