mysql开启gtid主从切换_Mysql5.6.21-GTID主从切换

实验环境:3台服务器,A,B,C

ba914df4bfa8a6033ae13bb03a8cf2cd.png

A-Master:192.168.112.131

B-Slave:192.168.112.132

C-Slave:192.168.112.129

一:查看当前复制状态。

1:查看 A,B,C 服务器TID。

A-master服务器:192.168.112.131

sql>show master status;

ffd5b0f954cc21cb7470487716f6482e.png

B-Slave服务器:192.168.112.132

sql>show slave status\G

e5b27530056918c9943f85984be2a9c8.png

C-Slave服务器:192.168.112.132

sql>show slave status\G

35b06f67c1ea203a9c7ccf86d23cc9d0.png

二:模拟数据不一致性,A主服务器宕机。

1:C-salve断开主从。

sql>stop slave;

2:A-Master插入新数据。

sql>create table t13(id int);

sql>create table t14(id int);

sql>create table t15(id int);

这个时候,我们可以发现,C服务器缺少13-15表的数据。B服务器是正常的。

3:模拟A服务器宕机,直接关闭A服务器的mysql服务。

$sh ../scripts/mysql_shutdown.sh

3c9a3ea483278188955088424465c8ab.png

4:查看B服务器状态。

sql>show slave status\G

590cbb01f3ae36d5bcafe8d08e7efbcc.png

三:将B-slave提升为主服务。

1:停止B服务器上的slave服务

sql>stop slave;

2:C服务器更改连接主服务器IP地址

sql>change master to master_host='192.168.112.132', master_user='ruser',master_password='rpass',master_auto_position=1;

4ac609620278db91474e5abf2a62a269.png

3:C服务器启动slave服务,查看C服务器状态。

sql>start slave;

6784ade9001244c37b0baffd156a37f9.png

sql>show slave status\G

8f127618f9e57ff1d3418ba1b7ca66cb.png

这里会发现一个疑问,为什么C服务器上的Executed_Gtid_set的值还是:7edc6fd5-e1bf-11e4-8842-000c29e512d6:1-16,

按照理论,GTID不是唯一的么?难道B和A服务器的GTID是一样的??记住这里执行的relay日志。relay日志记录的GTID值肯定是原来A服务器上的。

4:查看C服务器从B服务器复制的新数据。

sql>use testhuang;

sql>show tables;

686853a013e61d3e4253d2a617faff23.png

补充信息描述:

当前环境都是异步架构(非半同步),生产实际情况可能是C服务器复制的数据比较多,B还没来得及复制,A服务器

就宕机了。我们应该选择节点中,TID值最高的服务器做为主服务器。如果强制需要B服务器做为主,我们也应当让C先接管主,B服务连接C,数据都同步成功后,再进行切换。

回到刚才那个问题,为什么Executed_Gtid_set还是原来的值。我们先做一个实验。

5:B新主服务器添加新数据。

sql>create table t16(id int);

sql>create table t17(id int);

sql>create table t18(id int);

6:这个时候,我们执行show master status;

sql>show master status;

26659e0697a1b0f72694e877da1d8a16.png7d055966-e1bf-11e4-8842-000c2976947c:1-3

7edc6fd5-e1bf-11e4-8842-000c29e512d6:1-16

是否发现GTID的值变化了,一共有两行, ","隔开的,符合GTID的唯一理论了吧?因为之前的t13-t15是原来的GTID事务。所以C服务器在连接B服务器的时候,在没有添加任何数据之前,同步的信息标识还是A服务器的GTID值。我们可以同步relay日志查看。

7:C服务器上查看relay日志:

这里根据实际情况查看binlog日志文件。

$/usr/local/mysql56/bin/mysqlbinlog mysql-relay-bin.000002

55afabf38d6118e44e635b3044caed57.png

我们可以发现C服务器上运用的relay日志。可以得出结论,B服务器上的binlog日志也是一样的。

因为该日志是从B服务器上拉取下来的,不信可以去看看,所以就符合了同一个事务所有节点的

GTID值都是一致的。下面案列中,我们也会更充分证明。

四:A服务器恢复,加入从节点。

1:启动A服务器mysql服务。

$sh ../scripts/mysql_startup.sh

766ec5fe97ce0399e226c0a935b513e6.png

2:查看当前状态

sql>show master status;

e1fa417985e197532b6255be8da644ba.png可以看到A服务器的GTID值,是1-16.目前并没有连接新主服务器。

3:连接新数据库B.

sql>change master to master_host='192.168.112.132', master_user='ruser',master_password='rpass',master_auto_position=1;

96a928df02ead03c9b783db4e1e81b3a.png

4:启动slave服务。

sql>start slave;

5:查看数据同步状态。

sql>use testhuang;

sql>start tables;

3996e03b030c53b6d4cd114a0a5084a8.png

数据同t16-t18已经被同步过来了。

6:查看slave状态

sql>show slave status\G

e704f51cf95611b14d33532a19b8e9e2.png

我们可以发现,这里的Executed_Gtid_Set只有一个值,跟理论值完全对应。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值