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