MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点，如下图所示:
l 主节点 binary log dump 线程
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，在发送给从节点之前，锁会被释放。
l 从节点I/O线程
当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。
l 从节点SQL线程
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
主从复制延迟问题
如何查看？
与数据同步有关的时间点主要包括以下三个：
主库执行完一个事务，写入 binlog，将这个时刻记为 T1；
之后传给从库，将从库接收完这个 binlog 的时刻记为 T2；
从库执行完成这个事务，将这个时刻记为 T3。
所谓主从延迟，就是同一个事务，从库执行完成的时间与主库执行完成的时间之差，也就是 T3 - T1。
可以在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
产生原因？
主库不是实时同步从库
怎么解决？
半同步复制
在 MySQL 5.5 - 5.6 使用 after_commit 的模式下，客户端事务在存储引擎层提交后，在主库等待从库确认的过程中，主库宕机了。此时，结果虽然没有返回给当前客户端，但事务已经提交了，其他客户端会读取到该已提交的事务。如果从库没有接收到该事务或者未写入 relay log，同时主库宕机了，之后切换到备库，那么之前读到的事务就不见了，出现了幻读，也就是数据丢失了。
MySQL 5.7 默认值则是 after_sync，主库将每个事务写入 binlog，传给从库并刷新到磁盘 (relay log)。主库等到从库返回 ack 之后，再提交事务并且返回 commit OK 结果给客户端。 即使主库 crash，所有在主库上已经提交的事务都能保证已经同步到从库的 relay log 中，解决了 after_commit 模式带来的幻读和数据丢失问题，故障切换时数据一致性将得到提升。因为从库没有写入成功的话主库也不会提交事务。并且在 commit 之前等待从库 ACK，还可以堆积事务，有利于 group commit 组提交，有利于提升性能。
