首页 > 数据库 > > 16.1.5 在线 更改 服务器上的复制模式
参考官方文档:
https://dev.mysql.com/doc/refman/5.7/en/replication-mode-change-online.html
16.1.5.1 复制模式 概念
为了能够安全地配置在线服务器的复制模式,了解复制的一些关键概念非常重要。 本节介绍这些概念,并且在尝试修改在线服务器的复制模式之前是必读的。
MySQL中可用的复制模式依赖于识别被log的事务的不同技术。 复制使用的事务类型如下:
使用GTID时,您可以利用自动定位和自动故障转移,以及使用WAIT_FOR_EXECUTED_GTID_SET(),session_track_gtids和使用性能模式表监控被复制的事务。 启用GTID后,您无法使用sql_slave_skip_counter,而是使用空事务。
从运行MySQL先前版本的主服务器接收的中继日志中的事务可能根本不会出现任何特定事件,但在重放并记录在从属二进制日志中之后,它们前面会有一个Anonymous_gtid_log_event。
在线配置复制模式的能力意味着gtid_mode和enforce_gtid_consistency变量现在都是动态的,可以通过具有SUPER权限的帐户从顶级语句设置。在以前的版本中,这两个变量都只能在服务器启动时使用适当的选项进行配置,这意味着对复制模式的更改需要重新启动服务器。在所有版本中,gtid_mode可以设置为ON或OFF,这与GTID是否用于识别事务相对应。当gtid_mode = ON时,无法复制匿名事务,而当gtid_mode = OFF时,只能复制匿名事务。从MySQL 5.7.6开始,gtid_mode变量有两个额外的状态,OFF_PERMISSIVE和ON_PERMISSIVE。当gtid_mode = OFF_PERMISSIVE时,新事务是匿名的,同时允许复制的事务是GTID或匿名事务。当gtid_mode = ON_PERMISSIVE时,新事务使用GTID,同时允许复制事务为GTID或匿名事务。这意味着可以拥有一个复制环境,其中包含使用匿名和GTID事务的服务器。例如,具有gtid_mode = ON的主设备可以使用gtid_mode = ON_PERMISSIVE复制到从设备。 gtid_mode的有效值如下所示,顺序如下:
重要的是要注意,gtid_mode的状态只能基于上面的顺序一次改变一步。 例如,如果gtid_mode当前设置为OFF_PERMISSIVE,则可以更改为OFF或ON_PERMISSIVE但不能更改为ON。 这是为了确保服务器正确处理从匿名事务更改为在线GTID事务的过程。 当您在gtid_mode = ON和gtid_mode = OFF之间切换时,GTID状态(换句话说,gtid_executed的值)是持久的。 这可确保被服务器应用的GTID集始终保留,而不管gtid_mode类型如何变化。
作为MySQL 5.7.6引入的更改的一部分,与GTID相关的字段已经过修改,因此无论当前选择的gtid_mode如何,它们都会显示正确的信息。 这意味着,当没有GTID存在时,显示GTID集的字段(例如replication_connection_status Performance Schema表中的gtid_executed,gtid_purged,RECEIVED_TRANSACTION_SET和SHOW SLAVE STATUS的GTID相关结果)现在返回空字符串。 显示单个GTID的字段(例如,replication_applier_status_by_worker性能架构表中的CURRENT_TRANSACTION)在未使用GTID事务时显示ANONYMOUS。
使用gtid_mode = ON从主站复制提供了使用自动定位的功能,使用CHANGE MASTER TO MASTER_AUTO_POSITION = 1 语句来配置。 正在使用的复制拓扑影响是否可以启用自动定位,因为此功能依赖于GTID并且与匿名事务不兼容。 如果启用了自动定位并且遇到匿名事务,则会生成错误。 强烈建议在启用自动定位之前确保拓扑中没有剩余匿名事务,请参见第16.1.5.2节“在线启用GTID事务”。 主机和从机上的gtid_mode和自动定位的有效组合如下表所示,其中master的gtid_mode显示在水平线上,而slave的gtid_mode在垂直线上:

在上表中,条目为:
当前选择的gtid_mode也会影响gtid_next变量。 下表显示了服务器对gtid_mode和gtid_next的不同值的行为。

在上表中,条目是:
当二进制日志关闭且gtid_next设置为AUTOMATIC时,则不会生成GTID。 这与先前版本的行为一致。
16.1.5.2 在线启用GTID事务
本节介绍如何在online且使用匿名事务的服务器上启用GTID事务和(可选)自动定位。 此过程不需要使服务器offline,并且适合在生产中使用。 但是,如果您在启用GTID事务时可以使服务器offline,则该过程更容易。
在开始之前,请确保服务器满足以下前提条件:
以下过程可以随时暂停,之后可以恢复原状,或通过跳转到第16.1.5.3节“在线禁用GTID事务”的相应步骤进行恢复。 这使得该过程具有容错能力,因为可以像往常一样处理可能出现在过程中间的任何不相关的问题,然后在停止过程过后继续该过程。
注意:
在继续下一步之前,完成每个步骤至关重要。
启用GTID 事务
1.在每个服务器上,执行:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
让服务器在正常工作负载下运行一段时间并监控日志。 如果此步骤导致日志中出现任何警告,请调整应用程序,使其仅使用与GTID特性兼容,并且不会生成任何警告。
重要:
这是第一个重要步骤。 在进入下一步之前,必须确保错误日志中未生成警告。
2.在每个服务器,执行:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
3.在每个服务器,执行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
哪个服务器首先执行此语句无关紧要,但重要的是所有服务器在开始下一步之前均要完成此步骤。
4.在每个服务器,执行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
哪个服务器首先执行此语句无关紧要。
5.在每台服务器上,等待状态变量ONGOING_ANONYMOUS_TRANSACTION_COUNT为零。 可以使用以下方法检查:
SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
注意:
在复制从属设备上,理论上可能会再次显示零然后非零。 这不是问题,只要显示零一次。
6.等待直到上一步生成的所有事务都复制到所有服务器。 您可以在不停止更新的情况下执行此操作:唯一重要的是所有匿名事务都会被复制。
有关检查所有匿名事务是否已复制到所有服务器的一种方法,请参见第16.1.5.4节“验证匿名事务的复制”。
7.如果您将二进制日志用于复制以外的任何其他日志,例如时间点备份和还原,等到你不需要没有GTIDs事务的老二进制日志。
例如,在步骤6完成后,您可以在要进行备份的服务器上执行FLUSH LOGS。 然后显式地进行备份或等待您可能已设置的任何定期备份任务的下一次执行。
注意:
这是第二个重点。 至关重要的是要了解包含匿名事务的二进制日志,在没有GTID的情况下,在下一步之后无法使用。 完成此步骤后,您必须确保拓扑中的任何位置都不存在没有GTID的事务。
8. 在每个服务器上,执行
SET @@GLOBAL.GTID_MODE = ON;
9.在每台服务器上,将gtid-mode = ON添加到my.cnf。
现在可以保证所有事务都具有GTID(在步骤5或更早版本中生成的事务已经处理完)。 要开始使用GTID协议以便以后执行自动故障转移,请在每个从站上执行以下操作。 (可选)如果使用多源复制,请对每个通道执行此操作并包含FOR CHANNEL通道子句:
STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel']; START SLAVE [FOR CHANNEL 'channel'];
16.1.5.3 在线 禁用 GTID 事务
本节介绍如何在已联机的服务器上禁用GTID事务。 此过程不需要使服务器脱机,并且适合在生产中使用。 但是,如果您在禁用GTID模式时可以使服务器脱机,则该过程更容易。
该过程类似于在服务器联机时启用GTID事务,但是反转步骤。 唯一不同的是等待记录的事务复制的点。
在开始之前,请确保服务器满足以下前提条件:
1.在每个从站上执行以下操作,如果使用多源复制,请为每个通道执行此操作并包含FOR CHANNEL通道子句:
STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE = file, \ MASTER_LOG_POS = position [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];
2.在每个服务器,执行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
3.在每个服务器,执行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
4.在每台服务器上,等到变量@@ GLOBAL.GTID_OWNED等于空字符串。 可以使用以下方法检查:
SELECT @@GLOBAL.GTID_OWNED;
在复制从属设备上,理论上可能是空的,然后再次非空。 这不是问题,只要它空一次就足够了。
5.等待任何二进制日志中当前存在的所有事务都复制到所有从属服务器。 有关检查所有匿名事务是否已复制到所有服务器的一种方法,请参见第16.1.5.4节“验证匿名事务的复制”。
6.如果您将二进制日志用于复制以外的任何其他日志,例如进行时间点备份或还原:请等待,直到您不需要具有GTID事务的旧二进制日志。
例如,在步骤5完成后,您可以在要进行备份的服务器上执行FLUSH LOGS。 然后显式地进行备份或等待您可能已设置的任何定期备份例程的下一次执行。
重要:
这是此过程中的一个重点。 重要的是要了解包含GTID事务的日志在下一步之后无法使用。 在继续之前,您必须确保拓扑中的任何位置都不存在GTID事务
7.在每个服务器上,执行:
SET @@GLOBAL.GTID_MODE = OFF;
8.在每台服务器上,在my.cnf中设置gtid-mode = OFF。
如果要设置enforce_gtid_consistency = OFF,则可以立即执行此操作。 设置后,您应该将enforce_gtid_consistency = OFF添加到配置文件中。
如果要降级到早期版本的MySQL,可以使用正常的降级程序立即降级。
16.1.5.4 验证匿名事务复制
本节介绍如何监视复制拓扑并验证是否已复制所有匿名事务。 这在在线更改复制模式时很有用,因为您可以验证更改为GTID事务是否安全。
有几种方法可以等待事务复制:
最简单的方法,无论您的拓扑结构如何,但依赖于时序,如下所示:如果您确定从站永远不会超过N秒,则只需等待超过N秒。 或者等待一天,或者您认为安全部署的任何时间段。
一种更安全的方法,它不依赖于时间:如果您只有一个或多个从站的主站,请执行以下操作:
1.在master上,执行:
SHOW MASTER STATUS;
记下“文件和位置”列中的值。
2.在每个从站上,使用主站的文件和位置信息执行:
SELECT MASTER_POS_WAIT(file, position);
如果您有一个主站和多个级别的从站,或者换句话说您有slave的slave,请在每个级别上重复步骤2,从主站点开始,然后是所有直接从站,然后是从站的所有从站,依此类推。
如果使用循环复制拓扑,其中多个服务器可能具有写入客户端,请对每个主从连接执行步骤2,直到完成整个循环。 重复整个过程,以便完成两次完整的循环。
例如,假设您有三个服务器A,B和C,以圆形复制,以便A - > B - > C - > A.然后执行以下操作:
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/69946831/viewspace-3136344/ ,如需转载,请注明出处,否则将追究法律责任。