一、gtid模式
1.gtid模式的部署2.gtid模式优势3.gtid模式的半同步复制 二、mysql线程优化
1.延迟复制2.并行复制3.慢查询
一、gtid模式参考官网：
在所有的主从节点上（server 1 2 3）都要加上下面的这两句话：
gtid_mode=ON ###声明采用gtid模式
enforce-gtid-consistency=ON ###强制使用
SHOW SLAVE STATUSG; 出现两个yes就成功了，
server3也如此配置即可。
因此，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端）不用等。
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%
（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); 被记录了。
