Mysql5.6.21-GTID双主半同步

目录结构：
神马是半同步，同步，异步。

查看系统是否支持半同步。

加载半同步插件。

启动半同步。

查看半同步状态与测试。

多个slave,半同步。

半同步主从切换。

更换slave到新的master节点。

原Master恢复，加入新master节点。

GTID双主半同步构建。

Mysql在5.5版本引入了半同步的概念，在这里也普及一些基础知识。

一：神马是半同步，同步，异步。
1：Mysql的复制过程就是slave去master拉日志回来，存到relay文件中，然后执行。
2：Master根本不考虑数据是否达到了slave，或者slave是否执行成功了。
3：默认情况下mysql主从复制就是异步的方式，别看好像数据刚被创建，slve就可以看到了，因为你的数据量太小了，无法感受到异步的现象。
4：同步就是两边信息都完全一样，master确认了slvae数据复制并执行成功，才叫同步。

我们举个生产例子说明一下这件事。
生产中是否做过数据库读写分离？不管什么数据库，读写分离就是为了减轻数据库压力，假设我们有2台服务器，A是写入库，B是读库。用户注册了你网站的会员，注册的时候，是通过A库写入， 登录的时候是同步B服务器，对吧？

异步：
注册写到A库，应用前端直接返回注册成功，然后B库才到A库拉取新数据，在本地执行同步。如果由于网络，数据量等原因，B库还没有执行新数据，新用户就点击登录窗口，这个时候，应用前端就提示该用户尚未注册。。蛋疼了吧？？

同步情况：
注册写到A库，A库要把信息同步到B库，确定B库执行成功后，返回信息给前端，这个时候应用前端才显示注册成功。用户在注册后登录就不会出现异常了。这才符合逻辑吧？Mysql主从复制中，主库根本不去考虑从库是否把信息拷贝过去，或者成功执行了。

半同步又是什么概念？？
如果按mysql主从复制原理看，slave到master把数据垃取下来，然后执行，执行完后，把状态返回给master，这个时候应用程序才给客户端响应成功，这种延迟，用户都接受吗？找一个折中的方法：Mysql半同步在5.5版本横空出世。

半同步情况：
一主一从，一主多从情况下，Master节点只要确认至少有一个slave接受到了事务，即可向发起请求的客户端返回执行成功的操作，master节点是不需要等待slave节点成功执行完这个事务。slave节点接受到这个事务，并成功写入到本地relay日志中，就算是成功了。
半同步在数据完成性上得到了保障，起码主从架构中，有一个备份集，当然，这也不是说半同步配置成功，就不会丢失数据，都是有可能的，如sql执行错误,半同步失效,默认会自动转换成异步的方式,如果没有得到及时修复，将造成数据丢失。半同步有利有弊，势必会增加了成本开销，对数据库性能带来一定的影响,开源的就是这样。不然为什么Oracle要收费。哈哈。。

实验基础环境，可以参考之前发布的博客日志。《Mysql-Gtid主从复制》
http://jiajinh.blog.51cto.com/2085098/1632321

二：查看系统是否支持半同步
查看是否加载半同步插件。
sql> show plugins;
查找是否有semisync字母。如果没有跟着步骤走。

步骤1：查找mysql插件目录位置。
sql>show variables like 'plugin_dir';
+---------------+--------------------------------+
| Variable_name | Value |
+---------------+--------------------------------+
| plugin_dir | /usr/local/mysql56/lib/plugin/ |
+---------------+--------------------------------+

步骤2：查看目录文件是否存在。
$ll /usr/local/mysql56/lib/plugin/



我们可以发现有2个文件，一个是master.so 一个是slave.so，在主服务器加载master文件，在从服务器加载slave文件就可以。

实验环境描述：我们接着上一章的Mysql-Gtid复制。
A：192.168.112.131
B：192.168.112.132 （主Master）
C：192.168.112.129

三：加载半同步插件。
主服务器：192.168.112.132
sql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
查看是否加载插件
sql> show plugins;

rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL

从服务器：192.168.112.129
sql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

查看是否加载插件
sql> show plugins;

rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL

四：启动半同步插件。
Master：启用插件
（192.168.112.132）
sql>set global rpl_semi_sync_master_enabled = on;

Slave：启动半同步，slave要重启动IO线程，否则还是异步的方式同步数据。
（192.168.112.129）
sql>set global rpl_semi_sync_slave_enabled = on;
sql>stop slave IO_THREAD;
sql>start slave IO_THREAD;

五：查看半同步的状态。
1：在master中查看，slave是没有这几个信息的。
sql>show status like '%Rpl_semi_sync%';



解释几个重要的值。

Rpl_semi_sync_master_status	是否启用了半同步。
Rpl_semi_sync_master_clients	半同步模式下Slave一共有多少个。
Rpl_semi_sync_master_no_tx	往slave发送失败的事务数量。
Rpl_semi_sync_master_yes_tx	往slave发送成功的事务数量。

2：半同步几个参数设置
sql>show variables like '%Rpl%';



注释：

rpl_semi_sync_master_timeout	Master等待slave响应的时间，单位是毫秒，默认值是10秒，超过这个时间，slave无响应，环境架构将自动转换为异步复制
rpl_semi_sync_master_trace_level	监控等级，一共4个等级（1,16,32,64），后续补充详细。
rpl_semi_sync_master_wait_no_slave	是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on ，每一个事务都会等待，如果slave当掉后，当slave追赶上master的日志时，可以自动的切换为半同步方式，如果为off,则slave追赶上后，也不会采用半同步的方式复制了，需要手工配置。
rpl_stop_slave_timeout	控制stop slave 的执行时间，在重放一个大的事务的时候,突然执行stop slave ,命令 stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能，mysql 5.6可以通过rpl_stop_slave_timeout参数控制stop slave 的执行时间

3：半同步数据测试
Master添加数据
sql>create table t20(id int);
查看状态
sql>show status like '%Rpl_semi_sync%';



Rpl_semi_sync_master_no_tx： 0
Rpl_semi_sync_master_yes_tx： 1
可以看到执行成功，并返回了状态。

六：多个slave，半同步。
将C节点加入半同步。IP：192.168.112.129
1：加载激活C-slave节点服务器。
这四个步骤直接执行即可。前提是C节点是和B节点建立了GTID复制的环境。
sql>install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
sql>set global rpl_semi_sync_slave_enabled = on;
sql>stop slave IO_THREAD;
sql>start slave IO_THREAD;

2：在B主服务器查看状态。
sql> show status like '%Rpl_semi_sync%';



Rpl_semi_sync_master_clients：2 可以看到，节点的数量已经是两个了。

3：继续测试数据。
sql>create table t21(id int);
sql>show status like '%Rpl_semi_sync%';



Rpl_semi_sync_master_no_tx： 0
Rpl_semi_sync_master_yes_tx： 2
可以看到执行成功，并返回了状态。状态是2不是3，符合了理论值，半同步值确保有一台服务器接受到了数据。

七：半同步主从切换。
A：192.168.112.131（新Master）
B：192.168.112.132（Master）
C：192.168.112.129

考虑每个服务器都可能成为主服务器，所以都需要加载master主从插件，不激活就行了。
1：在主服务器加载半同步slave插件。
sql>install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

2：在从服务器加载半同步master插件。
sql>install plugin rpl_semi_sync_master soname 'semisync_master.so';

描述：模拟master宕机，A服务器接管服务。
3：模拟一下环境，先把C服务器的slave服务关闭。
标准的关闭slave方式，生产中，确保把已复制到relay的日志文件执行了。
sql>stop slave io_thread;
sql>stop slave;

4：B主manster服务器添加新数据。
sql>create table t22(id int);
sql>create table t23(id int);
sql>create table t24(id int);

5：B主master服务器关闭mysql服务。
$sh mysql_shutdown.sh




6：A服务器关闭slave服务，切换主数据库模式。
sql>stop slave io_thread;
sql>stop slave;
启动主库半同步插件。
sql>set global rpl_semi_sync_master_enabled = on;
sql>show status like '%Rpl_semi_sync%';



Rpl_semi_sync_master_clients：1 可以看到目前还没有新的slave连接自己。

八：更换slave到新的Master节点。
C节点加入新master服务器。
1：C节点连接新master服务器。
sql>change master to master_host='192.168.112.131', master_user='ruser',master_password='rpass',master_auto_position=1;

2：新master添加新数据。(192.168.112.131)
sql>create table t25(id int);
sql>create table t26(id int);
sql>create table t27(id int);

3：C节点启动slave服务，查看C节点slave状态。
sql>start slave;
sql>show slave status\G




4：A节点查看主从复制状态。
sql>show status like '%Rpl_semi_sync%';



Rpl_semi_sync_master_clients 1： 一个从节点
Rpl_semi_sync_master_no_tx 0： 没有错误
Rpl_semi_sync_master_yes_tx 3： 成功3次事务

九：原Master恢复，加入新master-A。
1：启动mysql服务
$sh mysql_startup.sh

2：与新master节点建立主从连接，启动slve服务。
先关闭slave服务
sql>stop slave;
sql>change master to master_host='192.168.112.131', master_user='ruser',master_password='rpass',master_auto_position=1;
sql>start slave;

3：查看主从复制状态（此刻是异步复制）
sql>start slave;




4：检查数据表是否成功同步。
sql>use testhuang
sql>show tables;




4：启动半同步。
sql>set global rpl_semi_sync_slave_enabled = on;
sql>stop slave IO_THREAD;
sql>start slave IO_THREAD;

5：主数据库查看状态。
sql>show status like '%Rpl_semi_sync%';



发现clients现在的值是2.

6：测试，主服务器添加数据测试。
省略.....................

十：GTID双主半同步。
A：192.168.112.131（Master）B：192.168.112.132（Master）C：192.168.112.129 (Slave)
开启双主比较简单，只需要在A服务器开启slave服务即可。
A:192.168.112.131
1：开启slave服务。
sql>start slave;




2：查看slave状态
sql>show slave status\G



我们看到是没有任何异常现象的。

3：B服务器添加新数据。
192.168.112.132
sql>create table t31(id int);
sql>show status like '%Rpl_semi_sync%';



这里是否发现，B服务器的半同步没有没有启动。之前不是启动过吗？因为重启动了B服务器的Mysql服务器，有心的朋友都会发现，我们并没有将半同步配置加入my.cnf文件中，所以失效了。。开启一下。

4：B服务器开启半同步
sql>set global rpl_semi_sync_master_enabled = on;
sql>create table t32(id int);
sql>show status like '%Rpl_semi_sync%';



这个时候是否发现，半同步也启用了，client的值只有1个，双主模式正式完成。是不是比之前的主从复制简单多了。

5：可以回头看A服务器的同步状态。
192.168.112.131
sql>show tables; #查看表是否创建。



可以看到表t31,t32

sql>show slave status\G #查看GTID是否正确


可以看到执行了GTID到 13 了，，刚好两个事务。

6：在A服务器创建新数据，查看主从状态。
A:192.168.112.131
sql>create table t33(id int);



我们可以发现，A服务器的client值等于2，因为A服务器有2个从，一个是互为双主的B，一个是slave-C。

7：再次查看A服务器的slave状态。
192.168.112.131
sql>show slave status\G



Retrieved_Gtid_Set: 7d055966-e1bf-11e4-8842-000c2976947c:1-13
Executed_Gtid_Set: 7d055966-e1bf-11e4-8842-000c2976947c:1-13,7edc6fd5-e1bf-11e4-8842-000c29e512d6:1-25
参数值分析：
Retrieved_Gtid_Set，读取主服务器B的事务位置。
Executed_Gtid_Set，这里有两个值，当在本地创建了t33表，我们发现，前面的7d055966-e1bf-11e4-8842-000c2976947c值并没有发生任何变化，7edc6fd5-e1bf-11e4-8842-000c29e512d6由1-24变成1-25。
可以看到，基于GTID复制，思路很清晰。一个是本地的UUID，一个是远程服务器的UUID值。这也是为什么会同时出现两个原因。
如果一个从服务器更换过N个主服务器，那么这个UUID也将会有多个，用"，"号隔开，这也符合了GTID事务的唯一性。