1、复制过程：
主库执行sql时，将事务日志存储到二进制日志文件（binlog）中，
并将binlog发送给从库，从库将会开启两个线程，一个线程将获取
到的binlog转存为中继日志（relaylog），另一个线程对relaylog中
的事件进行重放。
2、主从同步的类型：
（1）全同步复制（Fully synchronous replication）
主库执行完一个事务，且所有从库都执行了该事务才返回给客户端。因为需要等待所有从库才能返回，所以事务的时间会被拉长，从而性能必然会受到较大影响。
全同步是在 MySQL NDB Cluster 上采用的复制方式。NDB 是分布式存储引擎，无共享架构，严格来说 NDB 节点不是复制，而是 2PC，确保事务提交的强一致。该集群在国内使用极少，且存在较多问题，不建议采用。全复制会严重影响主库的事务提交性能，对网络要求非常严格，不适合同城、异地的架构场景。
（2）半同步复制（Semisynchronous replication）
主库需要等待至少一个从库节点收到日志事件，并刷新 Binlog 到 Relay Log 文件中的 ACK 确认消息后，才能提交并返回，主库一般不需要等待所有从库的 ACK。注意 ：该 ACK 是确保日志传送到从库并写入到中继日志，而不是从库已经完成重放、将数据写入完成。
（3）异步复制（Asynchronous replication）
主库在执行完客户端提交的事务后会立即提交并返回，不关心从库是否已经接收到日志并处理。如果此时主库上已经提交的事务因为某些原因未传送到从库，同时主库发生宕机，且在此时从库提升为主库，就会导致新主库数据缺失，从而造成主从数据不一致的情况发生。该复制模式下必然存在此问题。
主库将事务写入到 Binlog 文件中，并通知 dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，所以此时无法保证这些 Binlog 已经成功传到任何一个从库节点上。
