1. 一般的异常只需要跳过一步即可恢复
>slave stop;
>SET GLOBAL sql_slave_skip_counter = 1;
>slave start;
2.断电导致主从不能同步时，通主库的最后一个bin-log日志进行恢复
在主库服务器上，mysqlbinlog mysql-bin.xxxx > binxxxx.txt
tail -n 100000 binxxxx.txt > tail-binxxxx.txt
vim tail-binxxxx.txt 打开tail-binxxxx.txt文件找到最后一个postion值
然后在从库上，change host to 相应正确的值
>slave stop;
>change master to master_host=‘ip‘, master_user=‘username‘, master_password=‘password‘, master_log_file=‘mysql-bin.xxxx‘, master_log_pos=xxxx;
>slave start;
>show slave status\G;
3.主键冲突、表已存在等错误代码如1062,1032,1060等，可以在mysql主配置文件指定
略过此类异常并继续下条sql同步，这样也可以避免很多主从同步的异常中断
[mysqld]
slave-skip-errors = 1062,1032,1060
MySQL 复制的基本过程如下：
1. Slave 上面的IO 线程连接上Master，并请求从指定日志文件的指定位置（或者从
最开始的日志）之后的日志内容；
2. Master 接收到来自Slave 的IO 线程的请求后，通过负责复制的IO 线程根据请
求信息读取指定日志指定位置之后的日志信息，返回给Slave 端的IO 线程。返回信
息中除了日志所包含的信息之外，还包括本次返回的信息在Master 端的Binary Log
文件的名称以及在Binary Log 中的位置；
3. Slave 的IO 线程接收到信息后，将接收到的日志内容依次写入到Slave 端的
Relay Log 文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master 端的binlog
的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的
高速Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”
4. Slave 的SQL 线程检测到Relay Log 中新增加了内容后，会马上解析该Log 文
件中的内容成为在Master 端真实执行时候的那些可执行的Query 语句，并在自身执
行这些Query。这样，实际上就是在Master 端和Slave 端执行了同样的Query，所
以两端的数据是完全一样的。
实际上MySQL 自己早就想到了这一点，所以在MySQL 的Binary Log 中
记录了当前MySQL 的server-id，而且这个参数也是我们搭建MySQL Replication 的时候
必须明确指定，而且Master 和Slave 的server-id 参数值比需要不一致才能使MySQL
Replication 搭建成功。一旦有了server-id 的值之后，MySQL 就很容易判断某个变更是
从哪一个MySQL Server 最初产生的，所以就很容易避免出现循环复制的情况。而且，如果
我们不打开记录Slave 的Binary Log 的选项（--log-slave-update）的时候，MySQL 根
本就不会记录复制过程中的变更到Binary Log 中，就更不用担心可能会出现循环复制的情
形了。