mysql 主从 磁盘_Mysql主从同步

主从同步的作用：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模式后，所有提交的数据都已经被复制，故障切换时数据一致性将得到提升。