全局事务标示符(Global Transactions Identifier)是MySQL 5.6复制的一个新特性。它为维护特定的复制 拓扑结构下服务器的DBA们大幅度改善他们的工作状况提供了多种可能性。然而,你还应该明白当前实现的 一些局限。本博文是专门对在生产环境中启用GTID到底意味着什么进行讨论的一系列文章的第一部分。 这个手册非常到位地描述了如何才能切换到基于GTID的复制,我就不再鏊叙。 其基本步骤如下所示:
这个步骤会把你所有的服务器从普通复制切换到GTID复制。但是,如果你运行的是生产系统,你可能会想一 点一点启用GTID,这样一旦除了什么问题,也更容易进行回滚了。相关文档中有些条目写得不是很清楚。 比如:
为了找到这些问题的答案,先让我们创建一个比较简单的复制配置,其中有一个主机和两个从机,所有服务器 运行的都是MySQL 5.6,都未启用GTID。 首试:仅将其中的一个服务器配置为启用GTID让我们先停止2号从机的服务,修改配置后重启:
错误日志说明了为什么IO线程没有启动起来:
看来,很不幸的是,如果想要复制正常运行,gtid_mode必须在所有的服务器上都是ON或者都是OFF才行, 半半拉拉的绝对不行。 要是我们对主机进行重新配置会怎样?这次,1号从机的复制会停止运行:
这两个简单的试验回答了头两个问题:只有在所有的服务器中的gtid_mode具有相同的值时,复制才能正常运行, 因此,你应该对它们同时进行重启,而且最好是在将主机成为只读模式后进行。然而,“同时”的意思是“在同一个 binlog位置上”,所以你完全可以一个接一个对服务器进行重启。 再试:启用GTID,混合使用普通复制和GTID复制这次我们在1号从机而不是2号从机上启用GTID:
接下来让我们在主机上创建一个新表:
在两个从机上都运行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,的值进行区分:
结束语如果你的应用轻易不能容忍停机时间或者只读模式,那么基于GTID的复制启用起来就会非常棘手,特别在需要 重新配置大量服务器的情况下,便更是如此了。要是能将gtid_mode为ON的服务器同gtid_mode为OFF的服务 器混合使用就好了,因为这样的话,就就能够简化转向基于GTID的复制的所需的过程,如果出了错还更容易进行回滚。 英文原文:Replication in MySQL 5.6: GTIDs benefits and limitations – Part 1参与翻译(1人): |