Lamp架构——mysq集群及主从复制（2）
mysq集群及主从复制
- 一、异步主从复制
-
- 1.基于GTID的异步主从复制（非线性一主两从）
- 2.搭建“一主多从”结构——集群配置(由传统切换GTID模式)
- 二、半同步主从复制（Semisynchronous Replication）
-
- 1、半同步复制
- 2.半同步复制模式设置
- 3.测试
- 4.半同步模式AFTER_COMMIT和AFTER_SYNC的区别
- 三、延时复制
- 四、主从架构，SQL单线程优化，并行复制设置
- 五、慢查询
一、异步主从复制
主从复制的应用场景及异步主从复制的缺陷
主从复制比较重要的应用场景:主库的压力已经很高，但现在需要对主库数据进行备份，就可以利用主从架构对从库进行备份，在从机上对从库进行备份，这样对主库没有影响不会增大主库的压力，同时slave因为是从master复制的数据，所以数据是一致的。包括异地灾备系统等，异地灾备系统做不到实时的，只要捉到最终数据一致性就可以。主从复制做不到实时，因为复制技术一定有延迟，网络上也会有延迟。
异步主从复制的缺陷： 一主多从架构适用于读的请求远远高于写的请求,在性能上，master上的数据被slave复制过去，网络通信上可能会得不到保障，因为mysql默认情况下是以异步的方式把bin-log日志数据的更新发送到slave， 异步很快，但是master端不会管slave端是否收到数据，这就导致在实际生产中slave服务器从主库复制数据时，可能会因为网络不稳定等因素，导致salve端没有接收到数据，此时master与slave端数据将不一致。
主从复制策略类型：
- 「同步策略」：Master会等待所有的Slave都回应后才会提交，这个主从的同步的性能会严重的影响。
- 「半同步策略」：Master至少会等待一个Slave回应后提交。
- 「异步策略」：Master不用等待Slave回应就可以提交。
- 「延迟策略」：Slave要落后于Master指定的时间。
1.基于GTID的异步主从复制（非线性一主两从）
GTID的基本概念及应用
GTID的原理及使用
GTID(Global Transaction Identifiers)——全局传输识别标识
GTID (Golobal Transaction ID) 是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。
GTID 复制和传统复制的区别：在启动主从复制时，不需要指定 binlog 文件名和 postion 号，直接 auto 即可。MySQL 会自动读取最后一个 relay，获取到上次已经复制的 GTID 号，从此号码开始向后复制即可。在 MHA 高可用环境下，在主库无法 SSH 时，从库进行数据补偿更加便捷。
在GTID主从复制中，每个mysql数据库上都有一个唯一uuid，每个事务生成一个id，gtid由上面两者组合： uuid+事务id。
从MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。GTID (Global Transaction ID)是全局事务ID,当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务
一主一从的结构中，主服务器会自动寻找从服务器，因此GTID不需要特别配置。而一主多从结构中，主服务器故障时将会寻找距离它数据最“接近”的从服务器，将该从服务器切换为master后，另一从服务器需要指向新master服务器的二进制日志文件以及position号，但是因为网络延迟等因素，会导致各从服务器复制的进度不同，从服务器之间的position号会不同，需要重新配置，导致切换的维护成本较高，因此需要配置GTID。
2.搭建“一主多从”结构——集群配置(由传统切换GTID模式)
查看server5的master状态，主数据库
查看从数据库的slave状态
GTID全局时别，无论在哪个节点上，号是一样的，是同一组，只不过每个人执行到的号不同。
修改server5:master端配置文件，申明使用gtid模式，并重启生效
[root@server5 mysql]# vim /etc/my.cnf
gtid_mode=ON
enforce-gtid-consistency=ON
以下两个命令都可以重启
[root@server5 mysql]# systemctl restart mysqld
[root@server5 mysql]# /etc/init.d/mysqld restart
修改slave端server6配置文件,启动gtid模式
slave现在是随着服务开机自启的，现在停止slave服务，重新定义复制模式
mysql> stop slave;
mysql> change master to master_host='172.25.254.15', master_user='repl', master_password='westos', MASTER_AUTO_POSITION = 1;
mysql> start slave;
mysql> show slave status\G;
slave端：server7开启gtid
master端插入数据进行测试
可以看到slave端数据库同步成功
gtid的好处就是随着不同节点延迟的变化，各个节点的延时不一样，当master挂了的时候，找一个离他最近的slave接管，当新的slave连接到新的master上的时候，并不需要知道号到哪了，因为采用GTID模式的话，会自动寻找下一跳，设置时不需要指定master端的日志文件以及号，它是全局的，只要找下一跳就行。
转换成GTID模式的好处就是配置集群时会更加方便，因为在配置过程中，不需要知道每个节点切过去的二进制文件和号。
用文件方式保存时，尤其是在并行复制时在性能上可以优化一下，可以以表结构存储到数据库中，不要每次都持久化到文件中，每次持久到磁盘上，磁盘时慢设备，会影响性能。
二、半同步主从复制（Semisynchronous Replication）
优化异步复制IO线程不稳定造成的数据库不一致
与SQL线程相比IO线程更重要，负责数据的一致性，IO线程负责数据的复制，二进制日志复制到slave后就持久化到磁盘上，就不会丢失，至于SQL线程啥时候进行读取中继日志进行回放不重要。
主从架构的IO、SQL线程缺陷及优化
现在已经由原先的传统方式切换成GTID方式，但是在主从架构中依然存在问题，在整体架构中，IO线程不太稳定，因为默认情况下MASTER采用异步方式发送数据，slave端没有接收到的话，会导致主从数据不一致，数据不一致时主从复制就没有存在的意义。mysql从5.6版本已经有无损复制，但是5.6并不是真正的无损复制，在5.7版本才达到了真正的无损复制模式，也就是半同步模式。数据库的主从复制有多种方式，异步、半同步（采用最多，尤其是金融证券行业，对无损复制要求很高，要求强移植性）。
1、半同步复制
半同步复制帮助文档
半同步复制必须要求是GTID的模式
2.半同步复制模式设置
所有节点安装插件
master端和slave端安装的插件是不一样的。
master端（server5）安装插件
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
slave端安装插件,slave半同步模块
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
插件装错时不影响，不调用就行了
mysql本身有很多的模块，show plugins即可查看。
master端
slave端
通过SET GLOBAL参数修改选项，可以热生效，不需要重启数据库，在生产环境中不能随便重启数据库，除非有热备机存在。
修改master端参数
加入配置文件是永久生效的
查看变量参数及当前状态
slave端修改
slave端重启IO线程
server6
server7
写入配置文件/etc/my.cnf确保开机自启，开机自动生效。
3.测试
master端插入数据并进行测试
制造不成功，并进行测试
slave端停止IO线程，master会等待10s,之后会切换到异步模式。
半同步模式是为了确保无损，只要slave端接到数据存到本地后会有一个ack响应返回，master端没有收到时，会认为slave端没有收到数据。
slave端停止IO线程
重启slave端的IO线程
master端
4.半同步模式AFTER_COMMIT和AFTER_SYNC的区别
mysql5.6的半同步模式是AFTER_COMMIT，而mysql5.7以及mysql8.0是AFTER_SYNC，AFTER_SYN才是真正的无损模式。。
相比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;
master端插入数据进行测试
四、主从架构，SQL单线程优化，并行复制设置
Mysql主从并行复制MTS
基于组提交的并行复制
master端是多线程写入的，有很多用户会写入，但是slave端SQL线程是单线程的（SQL ->relaylog -> update ），这样会造成更大的延迟。所以需要采用并行复制，启用并行复制后，master是多线程，slave也是多线程进行回放，并行复制比单线程至少快80%。
mysql5.7的进步之处在于它并行复制的颗粒度更细致化，原先并行复制的依据是数据库，也就是一个数据库对应一个线程，但是如果所有的操作都在一个库，那还是只有一个线程，也就是并行的颗粒度不够细致。
利用的是组提交不是组复制
slave端在配置文件/etc/my.cnf中设置并行设置，开启16个worker线程，指的是16个SQL线程，原先的SQL线程会转换成一个协调线程，专门负责转发，这地方的work千万别设置为1，设置为1还不如等于0，work=1就会变成并行复制，并行复制模式由于worker=1和原来的单线程没有区别，而且可能会更低，因为一旦变为并行复制，原先的线程会变成协调线程进行转发，多了一层转发。
slave端设置多线程sql
存放master和relay_log信息的文件在并行复制模式下，会变更的很快，如果还以文件的方式存储，需要频繁刷新磁盘文件，对磁盘的IO访问过于频繁，压力太大，会影响性能。建议以表的形式存储在数据库系统中，存到mysql的table中。
重启数据库，生效设置
五、慢查询
激活慢查询功能
测试
