目 录
2.搭建“一主多从”结构——集群配置(由传统切换GTID模式)
4.半同步模式AFTER_COMMIT和AFTER_SYNC的区别
一 、GTID
一主多从架构适用于读的请求远远高于写的请求,使用异步同步master的数据到slave时,会因为网络等不稳定因素,导致salve端没有接收到数据,此时master只负责把数据binlog数据发送slave端不负责slave端是否收到。
在主从机上开启mysql
查看初始状态
1、引入GTID
GTID(Global Transaction Identifiers)——全局传输识别标识
一主一从的结构中,主服务器会自动寻找从服务器,因此GTID不需要特别配置。而一主多从结构中,主服务器故障时将会寻找距离它最“近”的从服务器,因此GTID需要手动配置。
2.搭建“一主多从”结构——集群配置(由传统切换GTID模式)
参考官方文档进行配置
修改server5:master端配置文件,申明使用gtid模式,并重启生效
修改slave端server6配置文件,启动gtid模式
重新定义复制模式
slave端:server7开启gtid
master端插入数据进行测试
查看状态提示
可以看到slave端数据库同步成功
gtid的好处就是随着不同节点延迟的变化,各个节点的延时不一样,当master挂了的时候,找一个离他最近的slave接管,当新的slave连接到新的master上的时候,并不需要知道号到哪了,因为采用GTID模式的话,会自动寻找下一跳,设置时不需要指定master端的日志文件以及号,它是全局的,只要找下一跳就行。
转换成GTID模式的好处就是配置集群时会更加方便,因为在配置过程中,不需要知道每个节点切过去的二进制文件和号。
二、主从架构的IO、SQL线程缺陷及优化
现在已经由原先的传统方式切换成GTID方式,但是在主从架构中依然存在问题,在整体架构中,IO线程不太稳定,因为默认情况下MASTER采用异步方式发送数据,slave端没有接收到的话,会导致主从数据不一致,数据不一致时主从复制就没有存在的意义。mysql从5.6版本已经有无损复制,但是5.6并不是真正的无损复制,在5.7版本才达到了真正的无损复制模式,也就是半同步模式。数据库的主从复制有多种方式,异步、半同步(采用最多,尤其是金融证券行业,对无损复制要求很高,要求强移植性)。
1、半同步复制
2.半同步复制模式设置
master端和slave端安装的相应插件。
master端安装插件
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
slave端安装插件
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
生效配置
通过SET GLOBAL参数修改选项,可以热生效,不需要重启数据库,在生产环境中不能随便重启数据库,
slave端重启IO线程才可生效
实现开机自动生效
3.测试
master端插入数据并进行测试
模拟不成功时状态测试
4.半同步模式AFTER_COMMIT和AFTER_SYNC的区别
mysql5.6的半同步模式时AFTER_COMMIT,而mysql5.7以及mysql8.0都是AFTER_SYNC。
相比SQL线程IO线程更重要,IO线程负责的是数据的一致性,IO线程主要负责复制数据,只要把数据复制过去就会持久化到本地磁盘上不担心丢失。SQL线程读取中继日志做回放,做快做慢只是时间问题,不会出现数据不一致的问题。
三、延时复制
延时复制,给了后悔的机会,比如将延迟设置为30分钟,30分钟之后再执行,此时在master端做了误操作比如delete动作,可以有30分钟挽救时间,slave端数据还存在,可以从slave端数据备份过来,再在slave端把delete动作跳过不做。
mysql> STOP SLAVE SQL_THREAD;
mysql> CHANGE MASTER TO MASTER_DELAY = 30;
mysql> START SLAVE SQL_THREAD;
mysql> show slave status\G;
测试
四、主从架构,SQL单线程优化,并行复制设置
master端是多线程写入的,有很多用户会写入,但是slave端SQL线程是单线程的(SQL ->relaylog -> update ),这样会造成更大的延迟。所以需要采用并行复制,启用并行复制后,master是多线程,slave也是多线程进行回放,并行复制比单线程至少快80%。