主备数据不一致导致的同步错误
1、网络的延迟
由于mysql主从复制是基于binlog的一种异步复制通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
2、主从两台机器的负载不一致
由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。
3、max_allowed_packet设置不一致
主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。
4、自增键不一致
key自增键开始的键值跟自增步长设置不一致引起的主从不一致。
5、同步参数设置问题
mysql异常宕机情况下，如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。
6、自身bug
mysql本身的bug引起的主从不同步，一般不会
7、版本不一致
特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面不支持该功能的情况。
sql_thread是根据主键匹配行记录，不会校验行数据；有没有主键的情况下，sql_thread是根据全表扫描匹配行记录，所以master更新在slave中找不到需要更新的行，报1032错误
Last_SQL_Error: Could not execute Update_rows event on table rsms.t_sys_file; Can’t find record in ‘t_sys_file’, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event’s master log mysql-bin.004186, end_log_pos 269313742
MySQL主从同步的1032错误，一般是指在从节点侧要更改(update、delete)的数据不存在，SQL_THREAD提取的日志无法应用故报错，造成同步失败;（Update、Delete、Insert一条已经delete的数据）。1032的错误本身对数据一致性没什么影响，影响最大的是造成了同步失败、同步停止。如果主主（主从）有同步失败，要第一时间查看并着手解决。因为不同步，会造成读取数据的不一致。应在第一时间恢复同步
更改my.cnf文件，在Replication settings下添加：
slave-skip-errors ＝ 1032 ;并重启数据库，然后start salve；它是只读参数，不能动态修改；这个参数针对gtid和传统复制有效，并且俩者的结果都一样。报错的SQL语句会跳过，但是其余的SQL还是正常执行。设置slave_skip_errors=1062或者1032在binlog_format是ROW的情况下，整个事务只会跳过报1062或者1032错误的sql，不执行这条SQL其余的sql正常进行。
ERROR 1062主键冲突的错误，无论binlog_format是ROW格式还是STATEMENT格式，从库发生主键冲突的行的值都会被主库同步过来的数据给覆盖掉，即认为在从库执行replace操作。
针对1032行找不到的错误，无论binlog_format是ROW格式还是STATEMENT格式，从库本地都会忽略这条SQL语句，不执行，只是执行事务的其他没有错误的SQL。
在binlog_format为ROW格式的情况下，在出现1032或者1062的情况下，并且table存在自增健为主键，并且在master上面执行insert操作的时候没有指定主键，这个时候需要注意主键的键值信息，很有可能在出现1032或者1062错误跳过之后master和slave俩者的主键下一个键值可能不一致。所以需要注意的操作有delete,insert,truncate。在binlog_format的格式是ROW格式的情况下面，无论是1032还是1062情况下设置sql_slave_skip_counter=1,它会将整个事务跳过去。在binlog_format的格式是statement的情况下,sql_slave_skip_counter=1并且是1062的错误，它会将整个事务跳过去。而针对1032错误，在整个事务当中出现修改一个主库存在，但是从库不存在的row的数据的时候，在从库是不会报错的，且该事务的其他sql语句是可以成功执行的。
