20.4.1 GTIDs 和 组复制
组复制使用GTIDs(全球事务标识符)来跟踪每个服务器实例上已经提交的事务。所有组成员都需要设置gtid_mode=ON
和enforce_gtid_consistency=ON
。来自客户端的 incoming事务在接收它们的组成员上被分配一个GTID。从源服务器外部异步复制通道中接收的已复制事务保留它们到达组成员时的GTIDs。
来自客户端的 incoming事务的GTIDs使用group_ replication_group_name
系统变量指定的组名称作为标识符的UUID部分,而不是接收事务的个体组成员的服务器UUID。因此,所有直接由组接收的事务都可以被识别,并且它们将被分组到GTID集中,不管哪个成员最初接收了它们。每个组成员都有一个连续的GTIDs块保留用于其使用,当这些GTIDs被消费时,它将保留更多。系统变量group_ replication_gtid_assignment_block_size
设置块的大小,缺省为每个块100万个GTIDs。
视图更改事件(View_change_log_event
),当新成员加入时由组自己生成,记录在二进制日志中时将获得GTIDs。默认情况下,这些事件的GTIDs使用group_ replication_group_name
系统变量指定的组名称作为标识符的一部分。您可以将Group Replication系统变量group_ replication_view_change_uuid
设置为使用alternative UUID在GTIDs中,以便轻松地区分来自组客户端的交易。这可以在您的设置允许failover之间的组,并且您需要识别并丢弃特定于备份组的交易时非常有用。alternative UUID必须与成员服务器UUID不同,也不能与使用ASSIGN_ GTIDS_TO_ANONYMOUS_TRANSACTIONS
选项的CHANGE REPLICATION SOURCE TO
语句应用于匿名事务的UUID不同。
GTID_ONLY=1
、REQUIRE_ROW_FORMAT = 1
和 SOURCE_AUTO_POSITION = 1
对于 Group Replication 通道 group_replication_applier
和 group_replication_recovery
生效。这些设置在创建 Group Replication 通道时自动生效,也可以在升级 replication 组中的成员服务器时生效。通常使用CHANGE REPLICATION SOURCE TO
语句设置这些选项,但请注意不能在 Group Replication 通道上禁用它们。这些选项设置后,组成员不会将文件名和文件位置保存到 replication 元数据存储库中。GTID 自动定位和 GTID 自动跳过用于在必要时找到正确的接收器和应用程序位置。
如果加入组的成员在其 GTID 集合中有不在现有组成员中的事务,它不能完成分布式恢复过程,也不能加入组。如果远程克隆操作已经执行,这些事务将被删除并丢失,因为加入成员的数据目录将被擦除。如果来自捐赠者的二进制日志进行了状态转移,这些事务可能与组的事务冲突。
在 Group Replication 停止状态下,如果对实例执行管理事务,可能会在成员上出现额外的事务。为了避免这种情况引入新的事务,请总是在执行管理语句前将sql_log_bin
系统变量设置为OFF
,然后在完成后设置回ON
:
SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;
将该系统变量设置为OFF
意味着,从该点开始直到您将其设置回ON
的所有事务都不会被写入二进制日志,也不具有GTIDs。
如果在加入成员上出现额外的事务,请检查受影响服务器的二进制日志,以了解额外事务实际包含什么内容。将成员的数据和GTID集与当前组中的成员数据和GTID集 reconcile 的最安全方法是使用 MySQL 的克隆功能将来自组中的服务器内容传输到受影响服务器上。有关如何执行此操作的说明,请见第7.6.7.3节,“克隆远程数据”。如果事务是必需的,请在成员成功加入后重新执行该事务。