mysql全局事务变量GTID

发布时间:2023年12月24日

?官网地址: MySQL :: MySQL Replication :: 2.6.5 Global Transaction ID System Variables

欢迎关注留言,我是收集整理小能手,工具翻译,仅供参考,笔芯笔芯.

MySQL 复制??/??...??/??全局事务 ID 系统变量

2.6.5 全局事务ID系统变量

本节中描述的 MySQL 服务器系统变量用于监视和控制全局事务标识符 (GTID)。有关其他信息,请参阅?第 2.3 节 “使用全局事务标识符进行复制”

  • binlog_gtid_simple_recovery

    命令行格式--binlog-gtid-simple-recovery[={OFF|ON}]
    系统变量binlog_gtid_simple_recovery
    范围全球的
    动态的
    类型布尔值
    默认值ON

    该变量控制当 MySQL 启动或重新启动时在搜索 GTID 期间如何迭代二进制日志文件。

    当?binlog_gtid_simple_recovery=TRUE为默认值时,?gtid_executed和 的值在启动时根据最新和最旧的二进制日志文件中的gtid_purged值计算 。Previous_gtids_log_event有关计算的说明,请参阅?系统gtid_purged变量。此设置在服务器重新启动期间仅访问两个二进制日志文件。如果服务器上的所有二进制日志都是使用 MySQL 5.7.8 或更高版本生成的,并且您使用的是 MySQL 5.7.8 或更高版本,则?binlog_gtid_simple_recovery=TRUE?始终可以安全使用。

    使用?binlog_gtid_simple_recovery=TRUE,?gtid_executed和?gtid_purged可能会在以下两种情况下初始化错误:

    • 最新的二进制日志是由MySQL 5.7.5或更早版本生成的,并且gtid_mode?是ON针对某些二进制日志但?OFF针对最新的二进制日志。

    • 在 MySQL 5.7.7 或更早版本上发出了一条SET @@GLOBAL.gtid_purged语句,并且该语句时处于活动状态的二进制日志SET @@GLOBAL.gtid_purged尚未被清除。

    如果在任一情况下计算出不正确的 GTID 集,即使稍后使用 重新启动服务器,它仍然不正确?binlog_gtid_simple_recovery=FALSE。如果服务器上出现上述任一情况,请?binlog_gtid_simple_recovery=FALSE?在启动或重新启动服务器之前进行设置。要检查第二种情况,如果您使用的是 MySQL 5.7.7 或更早版本,则在发出SET @@GLOBAL.gtid_purged?语句后记下当前二进制日志文件名,可以使用SHOW MASTER STATUS.?如果在清除该文件之前重新启动服务器,那么您应该设置?binlog_gtid_simple_recovery=FALSE.

    设置后 ,系统变量中描述的?计算?binlog_gtid_simple_recovery=FALSE?方法?将更改为迭代二进制日志文件,如下所示:?gtid_executedgtid_purgedgtid_purged

    • 的计算不是使用?Previous_gtids_log_event最新二进制日志文件中的 和 GTID 日志事件的值,而是gtid_executed?从最新的二进制日志文件进行迭代,并使用Previous_gtids_log_event找到值的第一个二进制日志文件中的 和任何 GTID 日志事件的值Previous_gtids_log_event?。如果服务器的最新二进制日志文件没有 GTID 日志事件,例如,如果?gtid_mode=ON使用过但服务器后来更改为?gtid_mode=OFF,则此过程可能需要很长时间。

    • Previous_gtids_log_event的计算?不是使用最旧的二进制日志文件中的值 ,而是从最旧的二进制日志文件中迭代,并使用第一个找到非空?值或至少一个 GTID 日志事件的二进制日志文件gtid_purged中的值?(表明 GTID 的使用从那时开始)。如果服务器的旧二进制日志文件没有 GTID 日志事件,例如,如果?最近才在服务器上设置,则此过程可能需要很长时间。?Previous_gtids_log_eventPrevious_gtids_log_eventgtid_mode=ON

    在 MySQL 版本 5.7.5 中,此变量被添加为?simplified_binlog_gtid_recovery,在 MySQL 版本 5.7.6 中它被重命名为?binlog_gtid_simple_recovery

  • enforce_gtid_consistency

    命令行格式--enforce-gtid-consistency[=value]
    系统变量enforce_gtid_consistency
    范围全球的
    动态的是的
    类型枚举
    默认值OFF
    有效值

    OFF

    ON

    WARN

    根据此变量的值,服务器通过仅允许执行可以使用 GTID 安全记录的语句来强制执行 GTID 一致性。您?必须在启用基于 GTID 的复制之前设置此变量?ON

    enforce_gtid_consistency可以配置的?值为 :

    • OFF:所有事务都允许违反GTID一致性。

    • ON:任何事务都不允许违反GTID一致性。

    • WARN:允许所有事务违反 GTID 一致性,但在这种情况下会生成警告。WARNMySQL 5.7.6 中添加。

    enforce_gtid_consistency当设置为 时,?只能记录可以使用 GTID 安全语句记录的语句?ON,因此此处列出的操作不能与此选项一起使用:

    --enforce-gtid-consistency仅当语句发生二进制日志记录时才生效。如果服务器上禁用了二进制日志记录,或者语句由于被过滤器删除而未写入二进制日志,则不会对未记录的语句检查或强制执行 GTID 一致性。

    有关更多信息,请参阅?第 2.3.6 节 “使用 GTID 进行复制的限制”

    在 MySQL 5.7.6 之前,布尔值?enforce_gtid_consistency?默认为OFF。为了保持与以前版本的兼容性,在 MySQL 5.7.6 中,枚举默认为OFF,不带值的设置?--enforce-gtid-consistency?将被解释为将值设置为?ON。该变量还具有多个值的文本别名:0=OFF=FALSE,?1=ON=TRUE,?2=WARN。这与其他枚举类型不同,但保持与以前版本中使用的布尔类型的兼容性。这些更改会影响变量返回的内容。使用SELECT @@ENFORCE_GTID_CONSISTENCY、?SHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY'、 和SELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY',都返回文本形式,而不是数字形式。这是一个不兼容的更改,因为@@ENFORCE_GTID_CONSISTENCY返回布尔值的数字形式,但返回文本形式?SHOW和信息模式。

  • gtid_executed

    系统变量gtid_executed
    范围全球的
    动态的
    类型细绳
    单元GTID 集

    当与全局范围一起使用时,此变量包含在服务器上执行的所有事务的集合以及已由语句设置的 GTID 的表示?。这与和?的输出中的列?的值相同?。该变量的值是 GTID 集,请参阅?GTID 集了解更多信息。?SET?gtid_purgedExecuted_Gtid_SetSHOW MASTER STATUSSHOW SLAVE STATUS

    服务器启动时,?@@GLOBAL.gtid_executed进行初始化。binlog_gtid_simple_recovery?有关如何迭代二进制日志以填充 的更多信息,请参阅 参考资料gtid_executed。然后,当执行事务或?执行任何语句时,GTID 会添加到集合中。?SET?gtid_purged

    在任何给定时间可以在二进制日志中找到的事务集等于?GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged);也就是说,二进制日志中尚未清除的所有事务。

    发出RESET MASTER会导致该变量的全局值(但不是会话值)重置为空字符串。除了由于 原因而清除该集合时,GTID 不会以其他方式从该集合中删除?RESET MASTER

    在 MySQL 5.7.7 之前,此变量还可以与会话范围一起使用,其中它包含当前会话中写入缓存的事务集的表示。MySQL 5.7.7 中已弃用会话范围。

  • gtid_executed_compression_period

    命令行格式--gtid-executed-compression-period=#
    系统变量gtid_executed_compression_period
    范围全球的
    动态的是的
    类型整数
    默认值1000
    最小值0
    最大值4294967295

    mysql.gtid_executed每次处理这么多事务时?压缩表。当服务器上启用二进制日志记录时,不会使用此压缩方法,而是?mysql.gtid_executed在每次二进制日志轮转时对表进行压缩。当服务器上禁用二进制日志记录时,压缩线程将休眠,直到执行了指定数量的事务,然后唤醒以执行表的压缩?mysql.gtid_executed。将此系统变量的值设置为0意味着线程永远不会唤醒,因此不使用这种显式压缩方法。相反,压缩会根据需要隐式发生。

    有关详细信息,?请参阅?mysql.gtid_execulated 表压缩。

    该变量在 MySQL 版本 5.7.5 中添加为 ,?executed_gtids_compression_period并在 MySQL 版本 5.7.6 中重命名为?gtid_executed_compression_period

  • gtid_mode

    命令行格式--gtid-mode=MODE
    系统变量gtid_mode
    范围全球的
    动态的是的
    类型枚举
    默认值OFF
    有效值

    OFF

    OFF_PERMISSIVE

    ON_PERMISSIVE

    ON

    控制是否启用基于 GTID 的日志记录以及日志可以包含的事务类型。--gtid-mode在 MySQL 5.7.6 之前,此变量是只读的,并且仅在服务器启动时使用 。在 MySQL 5.7.5 之前,使用 启动服务器?--gtid-mode=ON要求服务器也使用?--log-bin和?--log-slave-updates选项启动。从 MySQL 5.7.5 开始,这不再是一个要求。请参阅?mysql.gtid_execulated 表

    MySQL 5.7.6 允许动态设置此变量。您必须具有足够的权限才能设置全局系统变量。请参阅系统变量权限。?enforce_gtid_consistency必须先设置ON为 才能设置?gtid_mode=ON。在修改此变量之前,请参阅?第 2.4 节 “更改在线服务器上的复制模式”

    MySQL 5.7.6 及更高版本中记录的事务可以是匿名的,也可以使用 GTID。匿名事务依靠二进制日志文件和位置来识别特定事务。GTID 事务有一个唯一的标识符,用于引用事务。OFF_PERMISSIVEMySQL 5.7.6 中添加的和?模式ON_PERMISSIVE允许在拓扑中混合这些事务类型。现在不同的模式是:

    • OFF:新交易和复制交易都必须是匿名的。

    • OFF_PERMISSIVE:新交易是匿名的。复制事务可以是匿名事务,也可以是 GTID 事务。

    • ON_PERMISSIVE:新交易是GTID交易。复制事务可以是匿名事务,也可以是 GTID 事务。

    • ON:新事务和复制事务都必须是GTID事务。

    从一个值到另一个值的更改一次只能是一步。例如,如果?gtid_mode当前设置为?OFF_PERMISSIVE,则可以更改为?OFFON_PERMISSIVE,但不能更改为ON

    在 MySQL 5.7.6 及更高版本中,无论 的值 如何gtid_purged, 和?gtid_executed的值都是持久的?gtid_mode。因此,即使在更改 的值之后?gtid_mode,这些变量也包含正确的值。gtid_purged在 MySQL 5.7.5 及更早版本中, while和?的值gtid_executed不持久?gtid_mode=OFF。因此,更改为 后gtid_mode,?OFF一旦清除所有包含 GTID 的二进制日志,这些变量的值就会丢失。

  • gtid_next

    系统变量gtid_next
    范围会议
    动态的是的
    类型枚举
    默认值AUTOMATIC
    有效值

    AUTOMATIC

    ANONYMOUS

    <UUID>:<NUMBER>

    该变量用于指定是否以及如何获取下一个GTID。

    设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参阅?系统变量权限

    gtid_next可以采用以下任意值:

    • AUTOMATIC:使用下一个自动生成的全局事务ID。

    • ANONYMOUS:交易没有全局标识符,仅通过文件和位置来标识。

    • UUID格式为:?的全局事务 ID?NUMBER?。

    上述哪个选项准确取决于 的设置gtid_mode,?有关更多信息,请参阅第 2.4.1 节“复制模式概念” 。gtid_mode如果是,?则设置此变量无效?OFF

    将此变量设置为?UUID:NUMBER并提交或回滚事务后,SET GTID_NEXT必须在任何其他语句之前再次发出显式语句。

    在 MySQL 5.7.5 及更高版本中,DROP TABLE或者?DROP TEMPORARY TABLE在非临时表与临时表的组合上使用时,或者在使用事务性存储引擎的临时表与使用非事务性存储引擎的临时表的组合上使用时,会失败并出现显式错误。在 MySQL 5.7.5 之前,当 GTID 启用但未gtid_next启用 时AUTOMATICDROP TABLE与这些表组合一起使用时无法正常工作。(错误#17620053)

    在 MySQL 5.7.1 中,您不能执行任何语句?CHANGE MASTER TO、?START SLAVE、?STOP SLAVE、?REPAIR TABLE、?OPTIMIZE TABLE、?ANALYZE TABLE、?CHECK TABLE、?CREATE SERVER、?ALTER SERVER、?DROP SERVER、?CACHE INDEX、?LOAD INDEX INTO CACHEFLUSH、 或?RESETwhen?gtid_next设置为 ; 以外的任何值AUTOMATIC。在这种情况下,语句会失败并出现错误。MySQL 5.7.2 及更高版本中并不禁止此类语句?。(错误#16062608、错误#16715809、错误#69045)(错误#16062608)

  • gtid_owned

    系统变量gtid_owned
    范围全局、会话
    动态的
    类型细绳
    单元GTID 集

    该只读变量主要供内部使用。其内容取决于其范围。

    • 当与全局范围一起使用时,?gtid_owned保存当前在服务器上使用的所有 GTID 的列表,以及拥有它们的线程的 ID。该变量主要用于多线程副本检查事务是否已应用于另一个线程。应用程序线程在处理事务时始终获取事务 GTID 的所有权,因此@@global.gtid_owned?会在处理期间显示 GTID 和所有者。当事务被提交(或回滚)时,应用程序线程释放 GTID 的所有权。

    • 当与会话范围一起使用时,?gtid_owned保存当前由该会话使用和拥有的单个 GTID。当客户端通过设置显式为事务分配 GTID 时,此变量主要用于测试和调试 GTID 的使用?gtid_next。在这种情况下,?@@session.gtid_owned客户端在处理事务时始终显示 GTID,直到事务已提交(或回滚)。当客户端完成事务处理时,该变量被清除。如果?gtid_next=AUTOMATIC用于会话,?gtid_owned仅在执行事务的提交语句期间短暂填充,因此无法从相关会话中观察到它,尽管如果?@@global.gtid_owned在正确的点读取则列出它。如果您需要跟踪会话中客户端处理的 GTID,您可以启用由?session_track_gtids?系统变量控制的会话状态跟踪器。

  • gtid_purged

    系统变量gtid_purged
    范围全球的
    动态的是的
    类型细绳
    单元GTID 集

    gtid_purged系统变量( )?的全局值?@@GLOBAL.gtid_purged是一个 GTID 集合,由服务器上已提交但不存在于服务器上任何二进制日志文件中的所有事务的 GTID 组成。?gtid_purged是 的子集?gtid_executed。GTID 的以下类别位于?gtid_purged

    • 在副本上禁用二进制日志记录的情况下提交的复制事务的 GTID。

    • 写入二进制日志文件(现已被清除)的事务的 GTID。

    • 由语句显式添加到集合中的 GTID?SET @@GLOBAL.gtid_purged

    当服务器启动或重新启动时,全局值?gtid_purged被初始化为一组GTID。有关如何计算此 GTID 集的信息,请参阅系统gtid_purged变量。如果服务器上存在 MySQL 5.7.7 或更早版本的二进制日志,您可能需要?binlog_gtid_simple_recovery=FALSE?在服务器的配置文件中进行设置才能产生正确的计算。binlog_gtid_simple_recovery?有关需要此设置的情况的详细信息,?请参阅说明 。

    发出RESET MASTER会导致 的值gtid_purged重置为空字符串。

    您可以设置 的值,?gtid_purged以便在服务器上记录某个 GTID 集中的事务已被应用,尽管它们不存在于服务器上的任何二进制日志中。此操作的一个示例用例是当您正在恢复服务器上一个或多个数据库的备份,但您没有包含服务器上事务的相关二进制日志时。

    重要的

    GTID 仅在服务器实例上可用,最多为有符号 64 位整数(2 的 63 次方,负 1)的非负值的数量。如果将 的值设置?gtid_purged为接近此限制的数字,则后续提交可能会导致服务器用完 GTID 并采取 指定的操作?binlog_error_action

    gtid_purged在 MySQL 5.7 中,仅当?gtid_executed为空字符串 时才?可以更新 的值 ,因此gtid_purged为空字符串。当复制之前尚未开始,或者复制之前未使用 GTID 时,就会出现这种情况。在 MySQL 5.7.6 之前,?gtid_purged也仅在 时才可设置gtid_mode=ON。在 MySQL 5.7.6 及更高版本中,?gtid_purged无论 的值如何,都可以设置?gtid_mode

    要将 的值替换?gtid_purged为您指定的 GTID 集,请使用以下语句:

    SET @@GLOBAL.gtid_purged = 'gtid_set'
    笔记

    如果您使用的是 MySQL 5.7.7 或更早版本,在发出?SET @@GLOBAL.gtid_purged语句后,您可能需要?binlog_gtid_simple_recovery=FALSE?在重新启动服务器之前在服务器的配置文件中进行设置,否则?gtid_purged可能会计算错误。binlog_gtid_simple_recovery?有关需要此设置的情况的详细信息,请参阅说明 。如果服务器上的所有二进制日志都是使用 MySQL 5.7.8 或更高版本生成的,并且您使用的是 MySQL 5.7.8 或更高版本?binlog_gtid_simple_recovery=TRUE?(这是 MySQL 5.7.7 的默认设置),则始终可以安全地使用。

文章来源:https://blog.csdn.net/a309450028a/article/details/135168113
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。