主从复制是 MySQL 高可用（备份）和高性能（读写分离）的基础，有了这个基础，MySQL 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整。
要实施复制，首先必须打开 master 端的 binlog 功能，否则无法实现。因为整个复制过程实际上就是 slave 从 master 获取该 binlog 然后再在自己身上完全顺序的执行 binlog 中所记录的各种更新操作。
1.主从复制方式
1.1 异步复制
MySQL 主从复制默认是异步复制。
MySQL 增删改操作会全部记录在 binlog 中。当发生数据更新后，master 会将 SQL 记录通过多 dump 线程写入到 binlog 并发送给 slave。slave 把 binlog 存储到本地的 relay log 中，然后去执行 relay log 的更新内容。
这种模式下，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并处理。这样就会有一个问题，主节点如果崩溃，此时主节点上已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整。
1.2 半同步复制
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到 binlog 并写到 relay log 中才返回成功信息给客户端（只能保证主库的 binlog 至少传输到了一个从节点上）。
相对于异步复制，半同步复制提高了数据的安全性，一定程度上保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。
半同步模式不是 MySQL 内置的，从 MySQL 5.5 开始集成，需要 master 和 slave 安装插件开启半同步模式。
1.3 全同步复制
指当主库执行完一个事务，然后所有的从库都复制了该事务并成功执行完才返回成功信息给客户端。因为需要等待所有从库执行完该事务才能返回成功信息，所以全同步复制的性能必然会受到严重的影响。
2.主从复制原理
MySQL 主从复制涉及到三个线程：
- 一个在主节点的线程：binlog dump thread。
- 从库会生成两个线程：一个 I/O 线程，一个 SQL 线程。
主库会生成一个 log dump 线程，用来给从库 I/O 线程传 binlog。
从库 I/O 线程将得到的 binlog 写到本地的 relay log（中继日志）。
SQL 线程会读取 relay log，解析成 SQL 语句逐一执行。
3.主从复制时推还是拉？
MySQL 的复制是“推”的，而不是“拉”的。
“拉”是指 MySQL 的从库不断地循环询问主库是否有数据更新，这种方式资源消耗多，并且效率低。
“推”是指MySQL的主库在自己有数据更新的时候推送这个变更给备库，这种方式只有在数据有变更的时候才会发生交互，资源消耗少。
显而易见，“推”的方式更加符合程序运行的节能原则。
那么 MySQL 具体是怎么“推”的呢？
实际上从库在向主库申请数据变更记录的时候，需要指定从主库 Binlog 的哪个文件（MASTER_LOG_FILE）的具体偏移位置（MASTER_LOG_POS)。对应的，主库会启动一个 binlog dump 线程，将变更的记录从这个位置开始一条一条地发给从库。从库一直监听主库过来的变更，接收到一条，就会在本地应用这个数据变更。
参考文献
MySQL 主从复制原理不再难- rickiyang - 博客园
