*日志损坏。当主库日志损坏时，备库会因为读取不到目标偏移量的语句而停止，需要找出主库正常的首个语句的偏移量然后备库change master to重新定位。当备库日志损坏时通过最后执行的日志位置(execmaster log pos)找到主库对应的位置然后change master to重新定位。

日志损坏的类型：1.数据改变，但sql仍然有效，这种损坏不容易找出来，不过5.6版本后给binlog带上了checksum解决了这个问题。2.sql语句错误，这种语句中都是些错乱的数据。3.数据遗漏，mysqlbinlog无法处理这种日志会崩溃退出，这种可以通过十六进制查看器来找到日志的边界。

*对于非事务表崩溃会造成数据损坏，或者不使用stop slave关闭服务器也会导致问题。出现问题可以通过pt-table-sync来找到问题并同步数据，不过这建立在数据表仍然可用的基础上（表仍然可以打开结构仍然正确）。如果不行就只能重新导入该表数据或者使用备份恢复了。

*对于事务和非事务表混合的事务，如果在主库进行了回滚，事务表会回滚修改，而非事务表会永久保留修改，并且这个事务的日志仍然写入binlog，mysql在这里的处理是会给语句加上一句rollback，从而备库回放时能够保证结果一致（除非你中途kill了这个事务0）。

*不确定语句可能会导致主备不一致。比如说使用limit的update语句，主备上的顺序不一样会导致被更新的行不一致；replace或者insert ignore可能会在主备库上使用不同的索引；information_schema表中一些数据在主备库上可能不一致，对这些数据的操作存在不确定性。

*当备库的server id相同时会导致问题。备库可能会缓慢的进行正确的复制，也可能无法正确复制，因为两个备库间会存在竞争，他们会不断的与主库建立连接然后断开，这也可能会导致日志丢失或者重复执行事件，也会因为竞争导致主库开销增大。

*当备库崩溃或者重启时临时表也会造成一些问题。因为临时表一般保存在内存中，重启后临时表就会消失，这对后面依赖临时表的语句造成影响。可以通过保留一个专用数据库保存临时表，将每个连接的id拼接到表名上(模拟临时表仅连接可见的特性)，然后在使用完后将其删除（模拟连接关闭后临时表消失特性），这个工作的完成可以通过showprocesslist获取活跃的连接id，然后清理库中非活跃的临时表。

*关于innodb_locks_unsafe_for_binlog，设置这个参数会关闭innodb的间隙锁，间隙锁是为了防止幻读而出现的，间隙锁锁住了范围查询内的所有间隙，例如查询id>4的查询它会把大于4的id行插入都阻塞，从而防止两次范围查询间有新的行插入导致幻读关于间隙锁的解析可以看innodb下的记录锁，间隙锁，next-key锁。

*当出现过大的复制延迟的时候，可以通过pt-query-digest工具分析备库上的慢查询日志，找出是哪一些查询导致的问题还是写入负载太大导致的问题，如果是查询导致的问题可以看是否可以通过拆分查询等方式来加快速度，如果是负载过大，可以通过预读的方式（在早于重放事务的时候将事务修改为select语句将需要涉及的页预读进内存），从而提高实际重放时的速度，这样可以间接弥补单线程的限制，不过当备库是io密集型或者使用的不是innodb引擎或者插入查询占大多数的时候作用不大（插入本来就会有预读机制）。也可以通过设置innodb flush log at trx commit，delay key write，innodb locks unsafe for binlog等参数来减少刷新脏页到硬盘的次数，不过这也会导致一些安全隐患。

*当带宽不足的时候（尽管大部分时候带宽都不会成为瓶颈），可以通过对复制进行压缩来缓解，设置slave compressed protocol会用zlib引擎压缩连接，一般可以压缩到原大小的三分之一，付出的代价是主备库的cpu资源。