设为首页 收藏本站
查看: 3878|回复: 0

[经验分享] Mysql5.6.21-GTID主从切换

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-4-17 08:52:43 | 显示全部楼层 |阅读模式
实验环境:3台服务器,A,B,C
QQ截图20150417085227.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;
wKioL1Uvis7Cgn0SAAEpv1-JusM486.jpg

B-Slave服务器:192.168.112.132
sql>show slave statusG
wKiom1UviZPgcqu8AAGKkHqzw6o526.jpg

C-Slave服务器:192.168.112.132
sql>show slave statusG
wKioL1UvivuBDkepAAGKkHqzw6o186.jpg


二:模拟数据不一致性,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
wKiom1UviojAvAL1AACReuNhzGo125.jpg


4:查看B服务器状态。
sql>show slave statusG
wKioL1Uvi_rT3InJAAKrE_IfITQ013.jpg


三:将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;

wKiom1Uvir6ifjj2AACmNB2DIvs454.jpg


3:C服务器启动slave服务,查看C服务器状态。
sql>start slave;
wKioL1UvjCqi8cDmAAA8o1tiqgs752.jpg


sql>show slave statusG
wKiom1UviumAqBMvAAL2IfH550Q592.jpg
这里会发现一个疑问,为什么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;
wKiom1UvixSSbUQ7AAC6H2peyBM323.jpg
补充信息描述:

      当前环境都是异步架构(非半同步),生产实际情况可能是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;
wKioL1UvjKOwusoIAAFVfZKXfhw092.jpg 7d055966-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  
wKioL1UvjL7hsZj_AATucd4DpmE246.jpg
我们可以发现C服务器上运用的relay日志。可以得出结论,B服务器上的binlog日志也是一样的。
因为该日志是从B服务器上拉取下来的,不信可以去看看,所以就符合了同一个事务所有节点的
GTID值都是一致的。下面案列中,我们也会更充分证明。


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

1:启动A服务器mysql服务。
$sh ../scripts/mysql_startup.sh
wKioL1UvjOeSSj98AADBRcnE1PU383.jpg


2:查看当前状态
sql>show master status;
wKiom1Uvi5_iVcOaAAFQe1K2ZrQ213.jpg 可以看到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;
wKiom1Uvi7SyecJbAACTtfA5spM917.jpg

4:启动slave服务。
sql>start slave;


5:查看数据同步状态。
sql>use testhuang;
sql>start tables;
wKioL1UvjSDRrePYAAD3_GPCDU0706.jpg
数据同t16-t18已经被同步过来了。



6:查看slave状态
sql>show slave statusG
wKioL1UvjTbyhM8VAANpN0yEIvo337.jpg
我们可以发现,这里的Executed_Gtid_Set只有一个值,跟理论值完全对应。




运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-57918-1-1.html 上篇帖子: MySQL慢查询日志(二) 下篇帖子: PowerDesigner反向工程MySQL
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表