设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 技术文摘 查看内容

MySQL 5.6 复制:GTID 的优点和限制(第一部分)

2013-5-24 11:51| 发布者: 红黑魂| 查看: 9979| 评论: 0|来自: 开源中国

摘要: 全局事务标示符(Global Transactions Identifier)是MySQL 5.6复制的一个新特性。它为维护特定的复制拓扑结构下服务器的DBA们大幅度改善他们的工作状况提供了多种可能性。然而,你还应该明白当前实现的一些局限。本 ...
全局事务标示符(Global Transactions Identifier)是MySQL 5.6复制的一个新特性。它为维护特定的复制
拓扑结构下服务器的DBA们大幅度改善他们的工作状况提供了多种可能性。然而,你还应该明白当前实现的
一些局限。本博文是专门对在生产环境中启用GTID到底意味着什么进行讨论的一系列文章的第一部分。

这个手册非常到位地描述了如何才能切换到基于GTID的复制,我就不再鏊叙。

其基本步骤如下所示:

  • 让主机成为只读模式,这样就可以让从机执行所有的时间从而同主机保持为同步状态。
  • 修改所有服务器的配置并对它们进行重启
  • 使用CHANGE MASTER TO,让所有的服务器使用GTID
  • 关闭主机的只读模式

这个步骤会把你所有的服务器从普通复制切换到GTID复制。但是,如果你运行的是生产系统,你可能会想一

点一点启用GTID,这样一旦除了什么问题,也更容易进行回滚了。相关文档中有些条目写得不是很清楚。

比如:

  • 我们真地需要同时重启所有的服务器吗? 停机时间可是我们千方百计要避免的事情!
  • 有必要让主机变成只读模式吗?
  • 我们能不能在有些从机中使用普通复制的同时,在另外的一些从机上使用GTID复制?

为了找到这些问题的答案,先让我们创建一个比较简单的复制配置,其中有一个主机和两个从机,所有服务器

运行的都是MySQL 5.6,都未启用GTID。


首试:仅将其中的一个服务器配置为启用GTID

让我们先停止2号从机的服务,修改配置后重启:

1mysql> show slave status\G
2[...]
3Slave_IO_Running: No
4Slave_SQL_Running: Yes
5          [...]

错误日志说明了为什么IO线程没有启动起来:

12013-05-17 13:21:26 3130 [ERROR] Slave I/O: The slave IO thread stops because the master
has GTID_MODE OFF and this server has GTID_MODE ON, Error_code: 1593

看来,很不幸的是,如果想要复制正常运行,gtid_mode必须在所有的服务器上都是ON或者都是OFF才行, 

半半拉拉的绝对不行。

要是我们对主机进行重新配置会怎样?这次,1号从机的复制会停止运行:

12013-05-17 13:32:08 2563 [ERROR] Slave I/O: The slave IO thread stops because the master
has GTID_MODE ON and this server has GTID_MODE OFF, Error_code: 1593

这两个简单的试验回答了头两个问题:只有在所有的服务器中的gtid_mode具有相同的值时,复制才能正常运行,

因此,你应该对它们同时进行重启,而且最好是在将主机成为只读模式后进行。然而,“同时”的意思是“在同一个

binlog位置上”,所以你完全可以一个接一个对服务器进行重启。


再试:启用GTID,混合使用普通复制和GTID复制

这次我们在1号从机而不是2号从机上启用GTID:

1# slave #1
2mysql> change master to master_auto_position = 1;
3mysql> start slave;

接下来让我们在主机上创建一个新表: 

1mysql> create table test.t (id int not null auto_increment primary key);

在两个从机上都运行SHOW TABLES FROM test表明,所有的服务器都创建了这个新表。因此,一旦在所有的

服务器上启用GTID,你就可以让某些从机使用基于文件的定位而让另外一些从机使用基于GTID的定位。

这就回答了第二个问题:我们可以让不同的服务器具有不同的复制模式,但所有的服务器必须将将gtid_mode设

置为ON。在gtid_mode为ON的情况下还运行基于文件的复制,这能有什么意思?我还没有发现这有什么用处,

所以在实践中,你可能会要么只用基于文件的复制在(所有服务器都设置为gtid_mode=off),要么只用基于GTID

的复制(所有服务器都设置为gtid_mode=on)。


还有一个问题:如何通过查看SHOW SLAVE STATUS的输出才能看出来一个从机是不是基于GTID的复制?

这可以通过查看最后一个字段,Auto_Position,的值进行区分:

1# Slave #1
2mysql> show slave status\G
3[...]
4Auto_Position: 1  -> GTID-based positioning
5# Slave #2
6mysql> show slave status\G
7[...]
8Auto_Position: 0  -> File-based positioning


结束语

如果你的应用轻易不能容忍停机时间或者只读模式,那么基于GTID的复制启用起来就会非常棘手,特别在需要

重新配置大量服务器的情况下,便更是如此了。要是能将gtid_mode为ON的服务器同gtid_mode为OFF的服务

器混合使用就好了,因为这样的话,就就能够简化转向基于GTID的复制的所需的过程,如果出了错还更容易进行回滚。


英文原文:Replication in MySQL 5.6: GTIDs benefits and limitations – Part 1


参与翻译(1人)

酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部