Mariadb GTID 介绍

Posted 2021-05-01 小飞旅馆

一、       GTIT简述

自从Mariadb10.0.2Mariadb也支持了GTID, 而在官方mysql自从5.6也支持GTID,并且我们经常说Mariadb也兼容mysql官方版本，但是他们也是有些区别的，而我们要讲的GTID在两个版本中就是有区别的，并且区别还不小。官方中有段注释：

Note thatMariaDB and MySQL have different GTID implementations, and that these are notcompatible with each other.两者的实现方式都不一样，区别显而易见。

在主服务器上，对数据库（DML和DDL）的所有更新都将作为binlog事件写入二进制日志。从服务器连接到主服务器并读取binlog事件，然后在本地应用日志使复制节点与主服务器上做相同的更改。服务器可以同时是主服务器和从服务器，因此可以通过多级服务器复制binlog事件。

从服务器跟踪在从节点上应用的最后一个事件的主机binlog中的位置。这允许从服务器在临时停止复制后从其停止的位置重新连接和恢复。它还允许从节点断开连接，克隆，然后让新从设备从同一主节点恢复复制。

全局事务ID引入了附加到binlog中每个事件组的新事件。（事件组是始终作为一个单元应用的事件的集合。它们最好被认为是“事务”，尽管它们还包括非事务性DML语句以及DDL）。当事件组从主服务器复制到从属服务器时，将保留全局事务ID。由于ID在整个服务器组中是全局唯一的，因此可以轻松地在彼此复制的不同服务器上唯一标识相同的binlog事件（这在MariaDB 10.0.2之前不可能实现）。

二、          GTID好处

GTID能我们带来的好处：

1. 1.       轻松更改从属服务器以连接到不同主服务器并从其复制。

从数据库服务上会记住从旧主站应用的最后一个事件组的全局事务ID。这使得很容易知道在新主服务器上恢复复制的位置，因为全局事务ID在整个复制层次结构中是已知的。使用旧式复制时不是这种情况;在这种情况下，从节点只知道应用的最后一个事件的旧主服务器的特定文件名和偏移量。没有简单的方法可以从中猜出新主数据库服务器上的正确文件名和偏移量。

1. 2.       从服务器的状态以Crash-safe的方式记录。

 

从节点在mysql.gtid_slave_pos系统表中跟踪其当前位置（应用的最后一个事务的全局事务ID）。如果表使用事务存储引擎（例如InnoDB，这是默认设置），则状态更新将在与数据更新相同的事务中完成。这使得状态崩溃安全;如果从属服务器崩溃，重新启动时的崩溃恢复将确保记录的复制位置与实际复制的更改匹配。旧式复制不是这种情况，其中状态记录在文件relay-log.info中，该文件独立于实际数据更改而更新，并且如果从服务器崩溃，则很容易失去同步。（这适用于DML到事务表;非事务性表和DDL通常在MariaDB中不是崩溃安全的。）

由于这两个好处，通常建议对基于MariaDB 10.0.2或更高版本的任何复制设置使用全局事务ID。但是，旧式复制一如既往地继续工作，因此没有必要更改现有设置。全局事务ID与旧式复制平滑集成，并且两者可以在同一复制层次结构中一起自由使用。服务器无需特殊配置即可开始使用全局事务ID。但是，必须使用适当的CHANGE MASTER选项为从服务器明确设置它;默认情况下，复制从属使用旧式复制，以保持向后兼容性。

三、          GTID实现

全局事务ID（简称GTID）由三个用短划线“ - ”分隔的数字组成。例如： 0-1-10.

• 第一个数字0是域ID，它特定于全局事务ID（以下更多内容）。它是一个32位无符号整数。

• 第二个数字是服务器ID，与旧式复制中使用的相同。它是一个32位无符号整数。

• 第三个数字是序列号。这是一个64位无符号整数，对于登录到binlog中的每个新事件组，它会单调递增。

服务器ID设置为事件组首次登录binlog的服务器的服务器ID。对于记录的每个事件组，服务器上的序列号都会增加。由于服务器ID对于每个服务器必须是唯一的，这使得（server_id，sequence_number）对（因此整个GTID）全局唯一。

使用64位数字可以提供足够的范围，在可预见的将来不会出现溢出的风险。但是，不应该人为地（通过设置gtid_seq_no）注入具有接近64位限制的非常高序列号的GTID。

四、          域ID

当事件从主服务器复制到从属服务器时，事件始终以与从主服务器的binlog读取的顺序相同的顺序记录到从属的binlog中。因此，如果一次只有一个主服务器接收（非复制）更新，则binlog顺序在复制层次结构中的每个服务器上都是相同的。

从服务器使用一致的binlog顺序来跟踪其在复制中的当前位置。基本上，从服务器会记住从主服务器复制的最后一个事件组的GTID。当重新连接到主时，无论是相同的还是新的主，它都会将此GTID位置发送给主服务器，并且主服务器开始从相应事件组ID之后的第一个事件发送事件。

但是，如果用户更新是在多个服务器上同时独立完成的，那么通常所有服务器上的binlog顺序都不可能相同。使用多源复制，多主环拓扑，或者只是在从活动主服务器复制的从服务器上进行手动更新时，可能会发生这种情况。如果新主上的binlog顺序与旧主上的顺序不同，则从跟踪单个GTID以完全记录当前状态是不够的。

域ID是GTID的第一个部分，用于处理此问题。

通常，binlog不是单个有序流。相反，它由许多不同的流组成，每个流由其自己的域ID标识。在每个流中，GTID在每个服务器binlog中始终具有相同的顺序。但是，不同的流可以在不同的服务器上以不同的方式交错。

然后，从服务器通过记录每个复制流中应用的最后一个GTID来跟踪其复制位置。连接到新主服务器时，从服务器可以从binlog中的不同点开始针对每个域ID进行复制。

单一复制设置只允许应用程序在任何时候更新一个主服务器。在这样的设置中，只需要一个复制流。然后可以忽略域ID，并在所有服务器上保留默认值0。

五、          全局事务ID

从MariaDB 10.0.2开始，全局事务ID自动启用。记录到binlog的每个事件组都会收到一个GTID事件，如mysqlbinlog或SHOW BINLOGEVENTS所示。

从gtid_slave_pos变量可以看到，slave会自动跟踪上次应用的事件组的GTID：

SELECT @@GLOBAL.gtid_slave_pos

0-1-1

当从连接到主服务器时，它可以使用全局事务ID或旧式文件名/偏移量来决定主二进制日志中的开始复制的位置。要使用全局事务ID，请使用CHANGE MASTERmaster_use_gtid选项：

CHANGE MASTER TO master_use_gtid = { slave_pos |current_pos | no }

从配置为通过CHANGE MASTER tomaster_use_gtid = slave_pos。当从连接到主时，它将在复制到从的最后一个GTID的位置开始复制，这可以在变量gtid_slave_pos中看到。由于所有复制服务器中的GTID都相同，因此可以将从指向不同的主，并自动确定正确的位置。

但是假设我们设置了两个服务器A和B，让A成为主服务器，B成为服务器。它运行了一段时间。然后在某些时候我们取下A，B成为新的主。然后我们想要添加A，这次是作为从。

由于A之前从未是从，因此它没有任何先前复制的GTID，并且gtid_slave_pos将为空。要允许A自动添加为从服务器，可以使用master_use_gtid =current_pos。这将使用变量gtid_current_pos的值而不是gtid_slave_pos进行连接，这也考虑了当服务器是主服务器时写入binlog的GTID。

使用master_use_gtid =current_pos时，在使用CHANGE MASTER之前无需考虑服务器是主服务器还是从服务器。但是必须注意不要将额外的事务注入到从服务器上的binlog中，而不是要复制到其他服务器。如果从属启动时这样的额外事务是最新的，它将用作复制的起始点。这可能会失败，因为主服务器上不存在该事务。要避免从服务器上的本地更改进入binlog，请将sql_log_bin设置为0。

如果不希望对从节点上的binlog的更改影响GTID复制位置，则应使用master_use_gtid =slave_pos。然后，从节点将始终连接到最后一个复制GTID位置的主站。对于期望与传统复制一致的行为的用户而言，这可以避免一些意外，其中复制位置永远不会被服务器上的本地更改所改变。

当启用GTID严格模式时（通过将@@GLOBAL.gtid_strict_mode设置为1），通常最好使用current_pos。在严格模式下，不允许主服务器上的额外事务，即从服务器上不能随间更改。

如果从配置了禁用binlog，则current_pos和slave_pos是等效的。

即使将从节点配置为连接旧式binlog文件名和偏移量（CHANGE MASTER TOmaster_log_file = ...，master_log_pos = ...），它仍将跟踪@@GLOBAL.gtid_slave_pos中当前的GTID位置。这意味着以前配置和运行的现有从节点可以更改为与GTID（连接到相同或新的主站）连接，只需：

CHANGE MASTER TO master_use_gtid = slave_pos

从记住指定了master_use_gtid =slave_pos | master_pos，并将其用于后续连接，直到通过指定master_log_file /pos = ...或master_use_gtid = no显式更改它。当前值可以看作SHOW SLAVE STATUS的字段Using_Gtid：

SHOW SLAVE STATUS\G

...

Using_Gtid: Slave_pos

从服务器在内部使用mysql.gtid_slave_pos表来存储GTID位置（因此在服务器重新启动时保留@@GLOBAL.gtid_slave_pos的值）。将服务器升级到10.0后，必须运行mysql_upgrade（一如既往）才能创建表。

为了防止崩溃，该表必须使用事务存储引擎，如InnoDB。首次安装MariaDB（或升级到10.0.2+）时，使用默认存储引擎创建表 - 默认存储引擎默认为InnoDB。如果需要更改此表的存储引擎（例如，在使用MyISAM配置为默认存储引擎的系统上进行事务处理），请使用ALTER TABLE：

ALTER TABLE mysql.gtid_slave_pos ENGINE = InnoDB

不应以任何其他方式修改mysql.gtid_slave_pos表。特别是，不要试图更新表中的行来改变奴隶对当前GTID位置的看法; 改为使用

SET GLOBAL gtid_slave_pos = '0-1-1'

从MariaDB 10.3.1开始，服务器变量gtid_pos_auto_engines最好设置为使服务器自动处理。有关详细信息，请参阅mysql.gtid_slave_pos表的说明。

在10.0.2中，存储GTID位置的表的名称称为rpl_slave_state。使用语法master_use_gtid =0 | 1而不是master_use_gtid = no | current_pos。 master_use_gtid= slave_pos选项没有任何等效项。

六、          current_pos vs. slave_po

设置MASTER_USE_GTID复制参数时，可以选择启用全局事务ID通过设置 current_pos或slave_pos值。

使用值current_pos会使从服务器根据gtid_current_pos系统变量设置其位置。从服务器获取主服务器给它的位置。使用值slave_pos会导致slave改为使用gtid_slave_pos系统变量。使用此方法，从服务器会考虑其自己的二进制日志中存在的事务。

将MASTER_USE_GTID复制参数设置为current_pos时，可能会遇到问题。例如，如果在从节点停止时发出INSERT语句或以其他方式写入表，则当从节点重新启动时，由于GTID存在于从节点但主站不存在，MariaDB可能会生成错误。

您可以通过将MASTER_USE_GTID复制参数集更新为slave_pos来更正此问题。

CHANGE MASTER TO MASTER_USE_GTID = slave_pos;

START SLAVE;

 

 

七、          用GTID来创建一个新的slave

设置具有GTID新复制R 从服务器与设置传统主从复制没有太大区别。

基本步骤是：

1.设置新服务器并使用初始数据加载它。

2.从主的binlog中的适当点开始主从开始主从复制。

开启一个暂新空的数据库服务器来创建从服务器

用于测试目的的最简单方法可能是设置一个新的空从服务器并从头开始复制所有主服务器的binlog（这在实际的生产设置中通常是不可行的，因为初始binlog文件可能已被清除或需要太长的时间去应用所有的日志）。

从服务器以正常方式安装。默认情况下，新安装的服务器的GTID位置为空，这使得从属服务器从主服务器的binlog开始复制。但是如果从服务器以前用于其他目的，初始位置可以先显式设置为空：

SET GLOBAL gtid_slave_pos = "";

接下来，使用CHANGE MASTER将从指向主。像往常一样指定master_host等。但是不要手动指定master_log_file和master_log_pos，而是使用master_use_gtid =current_pos（或者slave_pos让GTID自动执行：

CHANGE MASTER TOmaster_host="127.0.0.1", master_port=3310,master_user="root", master_use_gtid=current_pos;

START SLAVE;

从备份中来创建

设置新复制从节点的常规方法是用现有服务器（无论是主服务器还是从服务器）的备份还原为新服务器，然后将其指向主服务器binlog中的适当位置开始复制主从。重要的是，启动复制的位置与准备备份的时间点的数据状态完全对应。否则，由于事务丢失或重复，从节点与主节点因为数据不一致而使从失败。

两种常见的备份方法是MariaDB Backup，它是MariaDB 10.1.23的分支提供的PerconaXtraBackup和mysqldump。这两者都可以以非阻塞方式提供备份的当前binlog位置。当然，如果在备份过程中没有对要备份的服务器进行写入，那么简单的SHOW MASTERSTATUS将给出正确的位置。

获取备份的当前binlog位置后，以binlog文件名和偏移量的形式，可以从备份的服务器上的BINLOG_GTID_POS（）获取相应的GTID位置：

SELECTBINLOG_GTID_POS("master-bin.000001", 600);

从版本10.0.13开始，mysqldump会自动执行此操作，并在使用--master-data或--dump-slave时在输出中包含GTID位置。

现在可以通过设置正确的@@ gtid_slave_pos，发出CHANGE MASTER以指向主服务器并启动从属线程来开始复制新的从节点：

SET GLOBAL gtid_slave_pos = "0-1-2";

CHANGE MASTER TOmaster_host="127.0.0.1", master_port=3310,master_user="root", master_use_gtid=slave_pos;

START SLAVE;

（从版本10.0.13开始，如果--gtid选项与--master-data或--dump-slave一起使用，mysqldump可以自动在输出中包含这些命令。）

从主服务器的备份设置新从服务器时，此方法特别有用。请记住确保新服务器的server_id值与任何其他服务器的值不同（在my.cnf中设置）。

如果备份是从现有的从服务器获取的，那么它已经在表mysql.gtid_slave_pos中存储了正确的GTID位置（假设备份包含此表并且与其他表的更改一致）。在这种情况下，不需要在旧服务器上显式查找GTID位置并将其设置在新的从服务器上 - 它已经从mysql.gtid_slave_pos正确加载。但是，如果备份是在主机上进行的，则这不起作用 - 因为当前的GTID位置包含在binlog中，而不是mysql.gtid_slave_pos中。

八、          从传统复制方式到GTID

如果已经存在使用旧式binlog文件名/偏移位置运行的现有从节点，则可以将其更改为直接使用GTID。例如，这可用于升级，或者已经存在使用旧式binlog位置设置新从节点的工具。

当从节点使用传统复制方式binlog文件与位置连接到主节点，并且主节点支持GTID（即MariaDB 10.0.2或更高版本）时，从节点在连接时会自动获取GTID的位置，并且随着复制而不断更新GTID位置并。因此，一旦从节点连过主节点一次后，就可以切换到使用GTID而无需任何其他操作。

STOP SLAVE;

CHANGE MASTER TOmaster_host="127.0.0.1", master_port=3310,master_user="root", master_use_gtid=current_pos;

START SLAVE;

（更高版本可能会添加一种设置从节点的方法，以便它第一次连接旧式binlog文件/偏移量，并在后续连接时自动切换到使用GTID。）

九、          更改从节点到不同的主节点

一旦使用GTID（master_use_gtid =current_pos | slave_pos）运行复制，只需在CHANGE MASTER中指定新的master_host（如果需要master_port，master_user和master_password），就可以将从节点指向新的master：

STOP SLAVE;

CHANGE MASTER TO master_host='127.0.0.1',master_port=3312;

START SLAVE;

从节点具有来自旧主节点的最后一个应用事务的GTID记录，并且由于GTID在复制层次结构中的所有服务器上是相同的，因此从节点将从新主节点的binlog中的适当点继续。

重要的是要了解主节点的变化是如何运作的。 binlog是一个有序的事件流（或多个流，每个复制域一个，（请参阅使用多源复制和其他多主设置）。流中的事件始终以相同的顺序应用于复制的每个从属 MariaDB GTID依赖于这种排序，因此仅记住流中的单个点即可。由于每个服务器上的事件顺序相同，切换到另一个服务器的binlog中相同GTID的点将给出相同的结果。

这转化为对用户的一些责任。MariaDB GTID复制完全异步，并且在如何配置方面完全灵活。这使得可以以违反所有服务器上的binlog序列相同的假设的方式使用它。在这种情况下，当更改master时，GTID仍将尝试在新binlog中的当前GTID点继续。

binlog序列在服务器之间变得不同的最常见方式是用户/ DBA直接在从属服务器上进行更新（并将这些更新写入从属binlog）。这会导致从节点binlog中的事件在主服务器或任何其他从服务器上不存在。这可以通过在执行此类更新时将会话变量sql_log_bin设置为false来避免，因此它们不会进入binlog。

通常最好避免服务器之间的binlogs有任何差异。 话虽如此，MariaDB复制的目的是为了获得最大的灵活性，并且有时可能有正当理由引入这些差异。在这种情况下，只需要了解GTID位置是每个binlog流中的单个点（每个复制域一个），以及它如何影响用户的特定设置。

当两个主服务器在复制层次结构中同时处于活动状态时，也会发生差异。使用多主环时会发生这种情况。但是，如果在切换到新主节点之前不允许旧主节点上的更改完全复制到所有从设备服务器，则在切换到新主节点期间，它也可以在简单的主从设置中发生。通常，要切换新的主从，应该停止对旧主节点的第一次写入，然后应该等待所有更改都复制到新主节点，然后才应该在新主节点上开始写入。还支持故意使用多个活动主服务器，这将在下一节中介绍。

GTID严格模式可用于在服务器之间强制执行相同的binlog。启用后，大多数可能导致差异的操作都会被拒绝并出现错误。

十、          多源复制与多主复制

MariaDB全局事务ID支持同时多个主服务器同时工作。通常，这会发生在多源复制或多主环设置中。

在此类设置中，必须为每个活动主服务器配置其自己的不同复制域ID gtid_domain_id。然后，binlog实际上由多个独立的流组成，每个活动主节点一个。在一个复制域中，每个服务器上的binlog顺序始终相同。但是，在不同的服务器binlog中，两个不同的流可以不同地交错。

然后，给定从节点的GTID位置不是单个GTID。 相反，它成为应用于域ID的每个值的最后一个事件组的GTID，实际上是每个binlog流中到达的位置。 当从节点连接到主节点时，它可以从与另一个流不同的binlog位置的一个流继续。由于一个流中的订单在所有服务器上都是一致的，因此这足以始终能够在任何新主服务器中的正确位置继续复制。

域ID由DBA根据应用程序的需要分配。@@ GLOBAL.gtid_domain_id的默认值为0.这适用于大多数复制设置，其中一次只有一个主服务器处于活动状态。 MariaDB服务器本身永远不会将新的domain_id值引入binlog。

使用多源复制时，如果单个从节点同时连接到多个主服务器，则应为每个此类主服务器配置其自己的不同域ID。

类似地，在多主环形拓扑中，环中的所有主节点由应用程序同时更新（使用某种机制以避免冲突），应为每个服务器配置不同的域ID（在多主机环中，应用程序小心一次只对一个主服务器进行更新，单个域ID就足够了）。

通常，从服务器不应接收直接更新（因为这会创建与主服务器相比的binlog差异）。因此，在从属设备上设置gtid_domain_id的值无关紧要，尽管使其与主设备（如果不使用多主设备）相同可以很容易地将从设备作为新主设备进行升级。当然，如果从属设备本身是活动主设备，如在多主环形拓扑中，则应根据服务器作为活动主设备的角色来设置域ID。

请注意，域ID和服务器ID是不同的概念。 可以在每个服务器上使用不同的域ID，但这通常是不可取的。它使当前的GTID位置（@@ global.gtid_slave_pos）更难以理解和使用，并且失去了跨所有服务器的单个有序binlog流的概念。建议配置尽可能多的域ID仅当应用程序同时主动更新主服务器。

错误地配置域ID本身并不是错误（例如，根本不配置它们）。 例如，这在升级方案中是典型的，其中使用5.5的多主环升级到10.0。即使所有内容都配置为使用默认域ID 0，该环仍将继续像以前一样工作。甚至可以使用GTID在服务器之间进行复制。但是，在将从节点切换到其他主节点时必须小心。如果旧主服务器和新主服务器之间的binlog顺序不同，那么从新主服务器的binlog中开始复制的单个GTID位置可能不够。

十一、   GTID新语法

CHANGE MASTER has anew option, master_use_gtid=[current_pos|slave_pos|no]

 

STARTSLAVE UNTIL master_gtid_pos=xxx

从节点将从当前GTID位置开始复制，运行并包括指定GTID的事件，然后停止。请注意，这会停止IO线程和SQL线程（与START SLAVE UNTILMASTER_LOG_FILE / MASTER_LOG_POS不同，后者仅停止SQL线程）。如果指定了多个GTID，则它们必须具有不同的复制域ID，例如： START SLAVE UNTIL master_gtid_pos =“1-11-100,2-21-50”在UNTIL条件下有多个域时，每个域只运行到包含指定位置，因此不同域可能停在binlog中的不同位置（每个域下次将在从节点启动时从停止位置继续）。

当使用STARTSLAVE UNTIL master_gtid_pos = XXX时，如果主机的binlog中存在UNTIL位置，则允许主机上缺少起始位置。在这种情况下，关联域的复制会立即停止。使用UNTIL master_gtid_pos时，两个从属线程必须已经停止，否则会发生错误。如果从节点未配置为使用GTID（CHANGE MASTER TO master_use_gtid = current_pos | slave_pos），则也是错误。 并且必须同时启动两个线程，IO_THREAD或SQL_THREAD选项不能仅用于启动其中一个。

START SLAVE UNTIL master_gtid_pos=XXX 特别适用于那种一主多从的情况，当主节点挂了的时候，我们需要在多个从节点中选出一个从节点来做为新的主节点，这个新的从节点必须比其它从节点拥有最新的事务从而减少或者避免减少事务的丢失。比如最个最新节点是S1, 其余的从节点我们称之为S2,S3,...Sn:

CHANGE MASTER TO master_host="S2";

    STARTSLAVE UNTIL master_gtid_pos = "<S2 GTID position>";

    ...

    CHANGEMASTER TO master_host="Sn";

START SLAVE UNTILmaster_gtid_pos = "<Sn GTID position>";

完成此操作后，S1将拥有任何服务器上都有的所有事务。 现在可以将其选为新主服务器，并将所有其他服务器设置为从中进行复制。

 

BINLOG_GTID_POS()

BINLOG_GTID_POS（）函数以文件名和文件偏移的形式将传统方式二进制日志位置作为输入。它在当前binlog中查找位置，并返回相应GTID位置的字符串表示。 如果在当前binlog中找不到位置，则返回NULL。

MASTER_GTID_WAIT

MASTER_GTID_WAIT函数是在MariaDB 10.0.9中引入的。 它在复制中用于控制主/从同步，并阻塞，直到从节点已读取并应用所有更新一直到主日志中的指定位置。 请参阅MASTER_GTID_WAITfor det

十二、   GTID相关的系统变量

• gtid_slave_pos

此变量是每个复制域在从节点上复制的最后一个事件组的GTID。用户可以设置它来更改当前复制位置。这需要首先停止所有从属线程。请注意，使用多源复制时，所有从节点连接之间共享该位置。要为两个主服务器（一个使用复制域1和另一个复制域2）设置位置，请为两个域设置GTID，例如：

SET GLOBAL gtid_slave_pos ="1-10-100,2-20-500";

只要在从节点上复制事件组，就会更新变量值。 当从节点配置为CHANGEMASTER TO master_use_gtid = slave_pos时，变量的值用作复制的起始点。

If this variable is set to a position that is notmore recent than the last GTID in the binary log on the server, a warning willbe given. This helps protect the user from setting one value for @@gtid_slave_pos, then being surprised when a slave configured with CHANGEMASTER TO master_use_gtid=current_pos startsreplicating at the more recent position found in the binary log. It also helpsprotect against the case where a server is rolled back to restart replicationfrom an earlier point in time, but the user forgets to also use RESETMASTER to roll back the binary log, thusgetting duplicate events in the binlog.

如果需要重置此值，则可以通过将其设置为空字符串来执行此操作：

SET GLOBAL gtid_slave_pos = '';

mysql.gtid_slave_pos系统表用于存储global.gtid_slave_pos的内容，并在重新启动时保留它。

• gtid_binlog_pos

对于每个复制域，此变量是写入二进制日志的最后一个事件组的GTID。请注意，当binlog为空（例如在全新安装或RESET MASTER之后）时，在任何复制域中都没有写入事件组，因此在这种情况下，gtid_binlog_pos的值将为空字符串。

The value is read-only, but it is updated whenevera DML or DDL statement is written to the binary log. The value can be reset byexecuting RESET MASTER,which will also delete all binary logs. However, note that RESET MASTER does notalso reset gtid_slave_pos.Since gtid_current_pos isthe union of gtid_slave_pos and gtid_binlog_pos, that means that new GTIDs added to gtid_binlog_pos can lag behind those in gtid_current_pos if gtid_slave_pos containsGTIDs in the same domain with higher sequence numbers. If you want toreset gtid_current_pos fora specific GTID domain in cases like this, then you will also have tochange gtid_slave_pos inaddition to executing RESETMASTER. See gtid_slave_posfornotes on how to change its value.

 

• gtid_binlog_state

变量gtid_binlog_state保存binlog的内部状态。状态包括为domain_id和server_id的每个组合记录到二进制日志的最后一个GTID。 主服务器使用此信息来确定给定的GTID是否已记录到过去的binlog中，即使之后由于binlog清除而被删除。对于每个domain_id，@@ gtid_binlog_state中的最后一个条目是登录到binlog的最后一个GTID，即。 这是@@ gtid_binlog_pos中显示的值。

通常，用户不需要此内部状态，因为@@gtid_binlog_pos在大多数情况下更有用。 @@gtid_binlog_state的主要用途是在RESET MASTER之后恢复binlog的状态（或者等同于binlog文件丢失）。 如果@@ gtid_binlog_state的值在RESETMASTER之前保存并在之后恢复，则master将保留有关过去历史的信息，就像使用了PURGE BINARY LOGS一样（当然二进制日志中的实际事务仍然被删除）。

请注意，要设置@@gtid_binlog_state的值，二进制日志必须为空，即它不能包含任何GTID事件，并且@@ gtid_binlog_state的先前值必须为空字符串。 如果没有，则必须首先使用RESETMASTER擦除二进制日志。

服务器通过写入文件MASTER-BIN.state来保留@@ gtid_binlog_state的值，其中MASTER-BIN是使用--log-bin选项设置的binlog的基本名称。 此文件在服务器关闭时写入，并在下一个服务器启动时重新读取。（如果服务器崩溃，MASTER-BIN.state中的数据不正确，服务器会在binlog崩溃恢复期间通过扫描binlog文件并记录找到的每个GTID来恢复正确的值）。

为了完整起见，请注意在内部设置@@gtid_binlog_state会执行RESET MASTER。 这通常不明显，因为它只能在binlog没有GTID事件时更改。 但是，如果执行，例如 升级到MariaDB10后，有可能binlog非空但没有任何GTID事件，在这种情况下，所有这些事件都将被删除，就像运行RESET MASTER一样。

• gtid_current_pos

此变量是每个复制域对数据库的最后一次更改的GTID。 此类更改可以是主节点事件（即，用户或应用程序进行的本地更改），也可以是源自另一个主服务器的复制事件。

对于每个复制域，如果@@gtid_binlog_pos中相应GTID的服务器ID等于服务器自己的server_id，并且序列号高于@@gtid_slave_pos中的相应GTID，则将使用来自@@ gtid_binlog_pos的GTID。 否则，来自@@ gtid_slave_pos的GTID将用于该域。

因此，@@ gtid_current_pos包含在服务器上执行的最新GTID，无论是作为主服务器还是作为从服务器执行。 当从节点配置为CHANGEMASTER TO master_use_gtid = current_pos时，此值用作复制的起始点。

该值是只读的，但只要将DML或DDL语句写入二进制日志和/或由从属线程复制，它就会更新。 如果需要重置该值，请参阅重置@@ gtid_slave_pos和@@gtid_binlog_pos的注意事项，因为@@gtid_current_pos是由这些变量的值组成的。

• gtid_strict_mode

GTID严格模式是一个可选设置，可用于帮助DBA强制执行严格的规则，以便在使用全局事务ID复制的多个服务器之间保持binlog相同。

启用GTID严格模式时，会针对可能导致复制层次结构中不同服务器上的binlog之间出现差异的情况启用一些其他错误：

a. 如果从属服务器尝试复制序列号低于该复制域的binlog中的序列号的GTID，则SQL线程将停止并显示错误（这表示主站中不存在从属binlog中的额外事务）。

b. 类似地，尝试手动对具有较低序列号的GTID进行binlog（通过设置@@ SESSION.gtid_seq_no）将被拒绝并出现错误。

b.如果从设备尝试从主设备binlog中缺少的GTID开始连接，则即使GTID存在具有更高序列号的GTID严格模式，这也是错误（这表示主设备上缺少从设备上的GTID）。 请注意，此错误由连接从属服务器上的GTID严格模式设置控制。

GTID模式默认关闭;这需要保持与现有复制设置的向后兼容性（旧版本的服务器不对binlog顺序强制执行任何严格模式）。即使未启用严格模式，全局事务ID也可以正常工作。但是，在强制执行严格模式的情况下，语义更简单，因此更容易理解，因为服务器之间的binlog顺序始终相同，并且每个复制域中的序列号始终严格增加。这还可以使大型复制设置的自动脚本更容易正确实现。

启用GTID严格模式后，遇到问题时从节点将停止并出现错误。这允许DBA意识到问题并采取纠正措施以避免将来出现类似问题。从这种错误中恢复的一种方法是暂时禁用有问题的从节点上的GTID严格模式，以便能够复制通过问题点（可能使用STARTSLAVE UNTIL master_gtid_pos = XXX）。

• gtid_domain_id

• last_gtid

• server_id

• gtid_seq_no

• gtid_ignore_duplicates

• gtid_pos_auto_engines

十三、   GTID and MariaDB GaleraCluster

从MariaDB 10.1.4开始，wsrep GTID复制和二进制日志GTID可以使用以下wsrep变量在群集节点上保持同步，这些变量使异步复制能够在任何剩余的Galera节点上进行故障转移。

 

wsrep_gtid_domain_id

Description: When wsrep_gtid_mode isset, this value is used as gtid_domain_id for galera transactions and alsocopied to the joiner nodes during state transfer. It is ignored, otherwise.

Commandline: --wsrep-gtid-domain-id=#

Scope: Global

Dynamic: Yes

Data Type: numeric

Default Value: 0

Range: 0 to 4294967295

Introduced: MariaDB 10.1.4

 

wsrep_gtid_mode

Description: Automatically update the (joiner) node's wsrep_gtid_domain_id valuewith that of donor's (received during state transfer) and use it in place ofgtid_domain_id for all galera transactions. When OFF (default),wsrep_gtid_domain_id is simply ignored (backward compatibility). If you areplanning to use Galera server with wsrep_gtid_mode as an async slave/master.

1. If theGalera node acts as an async master, then log-slave-updates shouldbe turned on.

2. If theGalera node is an async slave, then it should have a different domain id tothat of the master. If not, then Galera nodes may have a gtid (if sometransaction is run on the node) which will conflict with a future gtid from themaster.

3. If Galeranodes are in circular replication, then the Galera slave node should addignore_server_id= {all server ids of nodes in the same cluster, apart from itsown server id. }. For example, given the following cluster: A == B == C <--> D == E == F.A,B,C are cluster 1 and D, E, F are cluster 2. C and D are connected usingasync circular replication. C should ignore the server ids of A and B. D shouldignore the server ids of E and F. And by rule 1, both cluster 1 and cluster 2should have different domain ids.

Commandline: --wsrep-gtid-mode[={0|1}]

Scope: Global

Dynamic: Yes

Data Type: boolean

Default Value: OFF

Introduced: MariaDB 10.1.4

另祝大家平安夜快乐！！！