1、原理
MySQL复制技术有以下一些特点：
(1) 数据分布 (Data distribution )
(2) 负载平衡(load balancing)
(3) 备份(Backups)
(4) 高可用性和容错行 High availability and failover
整体上来说，复制有3个步骤：
(1) master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
(2) slave将master的binary log events拷贝到它的中继日志(relay log)；
(3) slave重做中继日志中的事件，将改变反映它自己的数据。
下图描述了复制的过程：
2、延时
原因：当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
解决：最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1（，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
sync_binlog
使用sync_binlog全局变量 1是最安全的值，但也是最慢的，使binlog在每N次binlog写入后与硬盘 同步
innodb_flush_log_at_trx_commit
默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的，设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统挂了时才可能丢数据。
3、mysql主从同步常见异常及恢复方法
a. 一般的异常只需要跳过一步即可恢复
>slave stop;
>SET GLOBAL sql_slave_skip_counter = 1;
>slave start;
b.断电导致主从不能同步时，通主库的最后一个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;
c.主键冲突、表已存在等错误代码如1062,1032,1060等，可以在mysql主配置文件指定
略过此类异常并继续下条sql同步，这样也可以避免很多主从同步的异常中断
[mysqld]
slave-skip-errors = 1062,1032,1060
参考
MYSQL主从不同步延迟原理
http://wxy021.blog.163.com/blog/static/170618669201298102732747/
MySQL主从同步常见异常及恢复方法
http://www.open-open.com/lib/view/open1409208341557.html