专栏地址：
1. MySQL主从复制的原理
MySQL的主库和从库之间通过binlog进行同步，是一种逻辑复制策略，主要涉及主库的binlog dump线程和从库的IO线程、SQL线程。
主库的binlog dump 线程和从库的 IO线程建立一个长链接，当：
- 主库的binlog dump线程监听到binlog文件变更时，通知从库的IO线程进行拉取；
- 从库IO线程发起请求并将返回的日志保存于relay log中；
- 从库的SQL线程监听relay log的变化，依次读取并进行重放。
主从延迟
主库的binlog dump 线程和从库的 IO线程都是单线程的，由于binlog是顺序写并且是组提交，所以效率较高。
而从库的SQL线程在默认条件下是单线程的，容易产生性能瓶颈，特别是遇到较大的DDL时。这是为了保证主从一致，并行重放需要保证依赖事务之间的执行顺序和主库一致，防止逆序执行导致更新覆盖等问题。MySQL5.7引入了多线程复制MTS（Multi-Threaded Slave），鉴于组提交中位于同一组内的事务之间不存在冲突（两阶段锁协议使得同时提交的事务不可能修改同一行），所以可以对同一组内多个事务的binlog进行并行重放。
coordinator为原SQL线程，现只负责读取日志和分发任务，worker线程负责真正的日志重放。
延迟的计算
2. binlog的格式
binlog是MySQL的一种二进制日志，以事件的形式记录了所有的DML和DDL操作，可用于归档（数据恢复）和复制（主从复制）。
binlog有三种格式，statement、row和mixed。
- statement：记录原始的SQL语句以及一些上下文信息（比如执行now函数时的时间戳）。
- 优点：占用空间小
- 缺点：相同语句在从库上执行仍然可能会产生不一样的结果，比如带有LIMIT的DELETE操作在主从上分别使用了不同的索引。
- row（推荐）：记录被修改行记录的所有细节，对于INSRET和DELETE记录所涉及行记录所有列的值，对于UPDATE则记录修改前后所有列的值。
- 优点：保证主从一致，且可用于误删时的数据恢复。
- 缺点：很占用空间
- mixed：混用statement和row格式，MySQL自动选择，对于可能会引起主从不一致的采用row格式。
- 优点：结合了statement和row的优点
推荐使用row格式，可用于数据恢复。
mysqldump和mysqlbinlog可以制作全量和增量的binlog。
参考
《MySQL实战45讲》