LAMP架构之mysql（3）：mysql两大线程的优化

一、gtid模式

参考官网：

1.gtid模式的部署

在所有的主从节点上（server 1 2 3）都要加上下面的这两句话：
 
gtid_mode=ON ###声明采用gtid模式
 
enforce-gtid-consistency=ON ###强制使用

SHOW SLAVE STATUS\G; 出现两个yes就成功了，

server3也如此配置即可。

2.gtid模式优势

因此，gtid模式总体优于主从复制模式。

但是，gtid也有他自己的缺陷，如下所示：

在IO这块，master采用异步方式来发送数据，slave端没有接收到的话会导致我们的数据不一致，数据不一致，那么整个结构就没有存在的意义了。

那么如何保证一致呢？

3.gtid模式的半同步复制

（1）安装插件

注意，参开官网，登陆数据库，在数据库里操作,主从节点安装的插件不一致：
 
master端（server1）：install plugin rpl_semi_sync_master soname ‘semisync_master.so’;
 
slave端（server2、3）： install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;

server2 3皆如此：

show plugins; 察看是否安装成功

（2）修改相关参数

设置参数启用半同步，并带有热生效，即修改后不需要重启服务
 
master：set global rpl_semi_sync_master_enabled=1;
 
slave：set global rpl_semi_sync_slave_enabled=1;
 
show variables like ‘rpl%’; 查看节点参数设置情况，可以看到rpl_semi_sync_master（slave）_enabled 已经设置成功
 
在这里rpl_semi_sync_master_timeout 是最大等待时间，100000ms，即10s后，master始终未等到来自skave的ack回应，则直接转为异步复制模式。

此时在两个slave节点查询节点状态： show status like ‘rpl%’;
 
会发现节点状态都是off，处于关闭状态，此时我们要重启IO线程，使节点生效。
 
stop slave IO_THREAD;
 
start slave IO_THREAD;
 
show status like ‘rpl%’; 状态变为on

在slave端做启动工作，server2 3 皆如此：

然后在master段可以看到下图所示效果：

在master端可以通过 show status like ‘rpl%’; 对节点简单管理
 
Rpl_semi_sync_master_clients 表示有几个slave节点
 
Rpl_semi_sync_master_yes_tx 表示复制成功的次数
 
Rpl_semi_sync_master_no_tx 表示复制失败的次数

设置开机自启：（注意master端和slave端不一样）

（3）测试效果

上图是成功的例子，下面我们来模拟不成功的例子：
首先停掉slave端的IO线程，用这种方法来模拟网络故障导致的数据不一致：

由于slave端的i线程关闭，master端会由半同步模式自动退回到异步模式，但是会等十秒：

当再次打开slave端的io线程后，会自动切回到半同步模式：

但是要注意，模式的切换并不影响数据的同步：

二、mysql线程优化

1.延迟复制

（1）.修改延迟复制参数

延迟复制是指从节点接收binlog后，等待一段时间再进行回放。
 
万一主节点误操作删掉重要信息，还有时间可以去从节点做个备份。
 
直接对从节点进行操作，这里用server2，登陆数据库状态。
 
具体操作如下：
 
STOP SLAVE SQL_THREAD;
 
change master to master_delay=30;
 
START SLAVE SQL_THREAD;

测试：

master端插入数据，在slave端的现实情况如下，他会一直计时：

server2端（slave端）的信息如下：

他只有等够时间才会复制数据过来。

但是server3（slave端）不用等。

2.并行复制

server2端：首先 show processlist; 查看未经优化前进程状态

然后，在/etc/my.cnf 文件中加入如下内容：
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
 
之后 重启数据库： /etc/init.d/mysqld restart 重启数据库

效果查看：
 
server2登陆数据库后，show processlist;
 
可看到很多作为协调的进程，16个

如此一来，由单线程变成了多线程，这样一定会加快它回放的速度，从之前的测试来看，至少可以提升80%

3.慢查询

（1）设置慢查询功能

应用场景：数据库查询时，有些命令运行半天没有回应，这类命令就算是异常命令，需要记录。这里在server1进行操作
 
server1：show variables like ‘slow%’; 查看服务状态，目前是关闭状态
 
打开服务：
 
set global slow_query_log=1;
 
show variables like ‘slow%’; 查看服务是否打开成功

由于慢查询是超过时间就会被记录 ，时间上限自然可以设置
 
show variables like ‘long%’; 查看时间上限
 
set long_query_time=5;修改最长等待时间
 
show variables like ‘long%’; 再次查看是否修改成功

（2）测试

select sleep(6); 执行一个等待六秒的函数
 
执行完后，去 /data/mysql/
 
查看记录 ： cat server1-slow.log
 
可以看到 select sleep(6); 被记录了。