主从同步的作用：1.数据热备，确保数据安全。2.读写分离，避免相互影响。3.架构的扩展，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
一.主从同步构型
1.一主一从（简单又实现了数据备份和服务器减压） 2.一主多从（提高读性能） 3.多主一从（5.7支持，将多个mysql数据库备份到一台存储性能比较好的服务器上）
3.双主复制（互为主从） 4.级联复制（缓解主节点压力）
二.主从同步原理
[从节点] I/O线程
当从节点上执行start slave命令之后，从节点会创建一个I/O线程来连接主节点，请求主库中更新的bin-log（增删改）。I/O线程接收到主节点bin-log dump 进程发来的更新之后，保存在本地relay-log中。
[主节点] bin-log dump(转存) 线程
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送（push）bin-log的内容。log dump 线程在读取bin-log时，会对其加锁，在读取完成后，发动给从节点前，锁会被释放。
[从节点] SQL线程
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
三.主从同步模式
异步模式[默认]
主库在执行完客户端提交的事务后会立即将结果返给客户端，只会通知一下 Dump 线程发送这些新的 Binlog，就会继续处理提交操作，并不会保证Binlog 传到任何一个从库节点上。
性能最佳，但如果主库crash了，此时主上已经提交的事务可能并没有传到从库上，可能导致数据不一致。
同步复制
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。
性能差，但数据一致性比较高。
半同步复制
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。当出现从库响应超时情况时，主库会暂时切换到异步复制模式，直到下一次同步没有超时转为半同步复制为止。（master的dump线程除了发送binlog数据到slave，还承担了接收slave的ack工作，dump线程必须等待slave返回ack之后才会传送下一个events事务。如果出现异常，没有收到ack，那么将自动降为普通的异步复制，直到异常修复）
性能较好，提高了数据的安全性。
AFTER_COMMIT（5.5，5.6默认值）：master将每个事务写入binlog之后，先提交事务，然后将binlog数据传递到slave并刷新到磁盘(relay log)。接着master等待slave反馈收到relay log，只有收到ack之后master才将commit OK结果反馈给客户端。
如果slave没有收到事务，也就是还没有写入到relay log之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从库，两边的数据就会出现不一致，slave会少一个事务的数据。
AFTER_SYNC（5.7默认值）
master将每个事务写入binlog，然后将binlog数据传递到slave并刷新到磁盘(relay log)。master等待slave反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。即使主库crash了，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。
MySQL5.7的半同步复制引入after_sync模式，主要是解决了after_commit导致的主库crash后主从之间数据不一致的问题。在引入after_sync模式后，所有提交的数据都已经被复制，故障切换时数据一致性将得到提升。