发布于 由admin

GTID` 模式的`底层`原理：它如何保证`主从`复制的`唯一性`与`一致性`？

GTID：保证主从复制唯一性与一致性的基石

大家好，今天我们来深入探讨一下 MySQL 中 GTID (Global Transaction Identifier) 模式的底层原理，以及它如何保障主从复制的唯一性与一致性。GTID 是 MySQL 5.6 引入的一项重要特性，彻底改变了传统基于二进制日志文件偏移量 (binlog offset) 的复制方式，显著提升了复制的稳定性和易用性。

1. 传统复制模式的挑战

在深入了解 GTID 之前，我们先回顾一下传统基于 binlog offset 的复制模式存在的一些问题：

  • 错误定位困难： 当从库复制中断时，需要手动查找主库上对应的 binlog 文件和偏移量，过程繁琐且容易出错。
  • 主从切换复杂： 主库发生故障需要切换时，需要精确记录新主库的 binlog 文件和偏移量，确保从库能从正确的位置继续复制。
  • 拓扑结构限制： 复杂的复制拓扑，例如多层复制或环形复制，管理起来非常困难，容易出现数据不一致的问题。
  • 无法保证事务的幂等性： 如果从库已经执行了主库上的某个事务，但由于网络问题导致 ACK 丢失，主库会认为该事务没有被复制，从而再次发送，导致从库重复执行。

这些问题都指向一个核心：传统复制模式依赖于物理位置（binlog 文件名和偏移量）来定位事务，而物理位置在不同的服务器上可能是不一致的，从而导致复制错误。

2. GTID 的核心思想：逻辑事务标识

GTID 模式的核心思想是用一个全局唯一的逻辑标识符来标识每一个事务，而不是依赖于物理位置。这个标识符在整个复制集群中都是唯一的，从而保证了事务的唯一性。

一个 GTID 由两部分组成：

  • server_uuid: 生成该 GTID 的服务器的 UUID。每个 MySQL 服务器都有一个唯一的 UUID，用于区分不同的服务器。
  • transaction_id: 在该服务器上产生的事务的序列号。从 1 开始递增。

因此，一个 GTID 的格式如下：server_uuid:transaction_id

例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23

这个 GTID 表示 UUID 为 3E11FA47-71CA-11E1-9E33-C80AA9429562 的服务器上产生的第 23 个事务。

3. GTID 的工作原理

GTID 模式的工作原理可以概括为以下几个步骤：

  1. 事务提交时生成 GTID： 当主库上提交一个事务时，MySQL 服务器会自动生成一个 GTID，并将该 GTID 写入到 binlog 中。这个 GTID 唯一标识了这个事务。

    -- 示例：在主库上执行一个事务
START TRANSACTION;
INSERT INTO users (name, email) VALUES ('Alice', '[email protected]');
UPDATE products SET stock = stock - 1 WHERE id = 1;
COMMIT;

    在主库的 binlog 中，将会记录类似如下内容（简化版）：

    # at 123
#190101 10:00:00 server id 1  end_log_pos 456 GTID  last_committed=0 sequence_number=1  assigned_gtid=3E11FA47-71CA-11E1-9E33-C80AA9429562:23
# at 456
#190101 10:00:00 server id 1  end_log_pos 789 Query   thread_id=13  exec_time=0  error_code=0
use `mydb`;
SET TIMESTAMP=1546300800/*!*/;
INSERT INTO users (name, email) VALUES ('Alice', '[email protected]')
/*!*/;
# at 789
#190101 10:00:00 server id 1  end_log_pos 1024 Query   thread_id=13  exec_time=0  error_code=0
use `mydb`;
SET TIMESTAMP=1546300800/*!*/;
UPDATE products SET stock = stock - 1 WHERE id = 1
/*!*/;
# at 1024
#190101 10:00:00 server id 1  end_log_pos 1234 Xid = 567
COMMIT/*!*/;

    可以看到，在事务的开始部分，记录了 assigned_gtid=3E11FA47-71CA-11E1-9E33-C80AA9429562:23，这就是该事务的 GTID。

  2. 从库请求 binlog 时携带 GTID 信息： 从库在连接到主库时，会告知主库自己已经执行过的 GTID 集合 (executed GTID set)。这个集合包含了从库已经成功执行的所有事务的 GTID。

    -- 示例：查看从库已经执行的 GTID 集合
SHOW SLAVE STATUSG

    在 SHOW SLAVE STATUS 的输出中，可以看到 Executed_Gtid_Set 字段，它表示从库已经执行过的 GTID 集合。例如：

    Executed_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-22,41A40999-71CB-11E1-9E33-C80AA9429562:1-5

    这个例子表示从库已经执行了以下 GTID：

    • 来自 UUID 为 3E11FA47-71CA-11E1-9E33-C80AA9429562 的服务器的 1 到 22 号事务。
    • 来自 UUID 为 41A40999-71CB-11E1-9E33-C80AA9429562 的服务器的 1 到 5 号事务。

  3. 主库发送未执行的事务： 主库接收到从库的 GTID 集合后，会比较自己的 GTID 集合和从库的 GTID 集合，找出从库尚未执行的事务，然后将这些事务发送给从库。

  4. 从库执行事务并更新 GTID 集合： 从库接收到主库发送的事务后，会执行这些事务，并将对应的 GTID 添加到自己的已执行 GTID 集合中。

    -- 示例：从库在执行完一个 GTID 为 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 的事务后，会更新自己的 GTID 集合。
-- 假设原来的 GTID 集合是 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-22,41A40999-71CB-11E1-9E33-C80AA9429562:1-5
-- 更新后的 GTID 集合将是 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-23,41A40999-71CB-11E1-9E33-C80AA9429562:1-5

    从库会将已执行的 GTID 集合持久化存储，通常存储在 mysql.gtid_executed 表中。

4. GTID 模式的优势

GTID 模式相比于传统复制模式，具有以下显著优势：

  • 简化复制配置： 不需要手动指定 binlog 文件名和偏移量，只需要指定主库的地址即可。
  • 自动故障转移： 当主库发生故障时，可以自动选择一个新的主库，从库会自动找到未执行的事务并继续复制，无需人工干预。
  • 避免数据不一致： 通过 GTID 保证了事务的唯一性，避免了事务的重复执行或遗漏执行，从而保证了主从数据的一致性。
  • 更强的容错性： 即使从库在复制过程中出现中断，也能在恢复后自动找到正确的位置继续复制。
  • 支持更灵活的复制拓扑： GTID 模式支持更复杂的复制拓扑，例如多层复制、环形复制等，并且管理起来更加方便。

5. GTID 模式的配置

开启 GTID 模式需要在 MySQL 服务器的配置文件 (my.cnf) 中进行配置。以下是一个简单的配置示例：

[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
server_id = 1
log_bin = mysql-bin
binlog_format = ROW
  • gtid_mode = ON: 开启 GTID 模式。
  • enforce_gtid_consistency = ON: 强制 GTID 一致性。开启此选项后，MySQL 会阻止所有可能导致 GTID 不一致的操作，例如在没有开启 binlog 的情况下执行事务。
  • log_slave_updates = ON: 在从库上记录从主库接收到的更新。这个选项对于多层复制非常重要。
  • server_id = 1: 设置服务器 ID。每个服务器必须有一个唯一的 ID。
  • log_bin = mysql-bin: 开启二进制日志。GTID 依赖于二进制日志。
  • binlog_format = ROW: 设置二进制日志的格式为 ROW。ROW 格式记录了每一行数据的修改，可以保证复制的准确性。

配置完成后，需要重启 MySQL 服务器才能生效。

6. GTID 的实现细节

为了更好地理解 GTID 的工作原理，我们来深入探讨一下 GTID 的一些实现细节：

  • GTID 的存储： GTID 的存储主要涉及到两个方面：

    • binlog: GTID 作为 binlog event 被记录在 binlog 文件中。
    • mysql.gtid_executed 表： 从库会将已经执行的 GTID 集合存储在 mysql.gtid_executed 表中。这个表用于记录从库的复制进度。

    mysql.gtid_executed 表的结构如下：

    CREATE TABLE `gtid_executed` (
  `source_uuid` char(36) NOT NULL COMMENT 'UUID of the source server that created the event',
  `interval_start` bigint(20) NOT NULL COMMENT 'First number of interval',
  `interval_end` bigint(20) NOT NULL COMMENT 'Last number of interval',
  PRIMARY KEY (`source_uuid`,`interval_start`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

    这个表使用 source_uuid 和 interval_start 作为主键，用于高效地查询和存储 GTID 集合。interval_start 和 interval_end 定义了一个 GTID 区间，例如 interval_start=1 和 interval_end=10 表示 GTID source_uuid:1 到 source_uuid:10 都被执行了。

  • GTID 的生成： GTID 的生成过程由 MySQL 服务器自动完成。当一个事务开始提交时，服务器会检查当前是否已经分配了 GTID。如果没有，则会生成一个新的 GTID，并将该 GTID 与该事务关联起来。GTID 的生成过程是原子性的，可以保证 GTID 的唯一性。

  • GTID 的传播： GTID 的传播主要通过 binlog 进行。主库将包含 GTID 的 binlog event 发送给从库，从库接收到 binlog event 后，解析出 GTID，并将该 GTID 添加到自己的已执行 GTID 集合中。

  • GTID 的一致性： 为了保证 GTID 的一致性，MySQL 引入了 enforce_gtid_consistency 参数。当该参数设置为 ON 时，MySQL 会强制执行以下规则：

    • 只有在开启 binlog 的情况下才能执行事务。
    • 不允许执行 CREATE TABLE ... SELECT 语句。
    • 不允许执行 LOAD DATA INFILE 语句。

    这些规则可以避免在没有 GTID 的情况下执行事务，从而保证 GTID 的一致性。

7. GTID 的使用场景

GTID 模式在很多场景下都非常有用，例如：

  • 主从复制： GTID 模式是主从复制的基础。它可以简化复制配置，提高复制的稳定性和可靠性。
  • 故障转移： 当主库发生故障时，可以使用 GTID 模式自动进行故障转移，减少人工干预。
  • 在线升级： 在进行 MySQL 在线升级时，可以使用 GTID 模式保证数据的一致性，减少停机时间。
  • 数据库迁移： 在进行数据库迁移时，可以使用 GTID 模式将数据从一个数据库迁移到另一个数据库，保证数据的完整性。

8. GTID 的一些注意事项

在使用 GTID 模式时，需要注意以下几点：

  • 必须开启 binlog： GTID 依赖于 binlog，因此必须开启 binlog。
  • 建议使用 ROW 格式的 binlog： ROW 格式的 binlog 记录了每一行数据的修改，可以保证复制的准确性。
  • 确保所有服务器的 UUID 都是唯一的： 每个 MySQL 服务器必须有一个唯一的 UUID，用于区分不同的服务器。
  • 合理配置 gtid_mode 和 enforce_gtid_consistency 参数： 这两个参数对于 GTID 的行为有很大的影响，需要根据实际情况进行配置。
  • 监控 GTID 的状态： 需要定期监控 GTID 的状态，例如已执行的 GTID 集合、未执行的 GTID 集合等，及时发现和解决问题。
  • 升级到支持 GTID 的 MySQL 版本： GTID 是 MySQL 5.6 引入的特性，因此需要升级到支持 GTID 的 MySQL 版本才能使用 GTID 模式。

9. 代码示例：GTID 相关的 SQL 语句

以下是一些与 GTID 相关的 SQL 语句示例：

  • 查看 GTID 模式的状态：

    SHOW GLOBAL VARIABLES LIKE 'gtid_mode';

  • 查看 enforce_gtid_consistency 的状态：

    SHOW GLOBAL VARIABLES LIKE 'enforce_gtid_consistency';

  • 查看服务器的 UUID：

    SHOW GLOBAL VARIABLES LIKE 'server_uuid';

  • 查看从库的复制状态（包含 GTID 信息）：

    SHOW SLAVE STATUSG

  • 跳过一个 GTID：

    SET gtid_next='3E11FA47-71CA-11E1-9E33-C80AA9429562:24';
BEGIN;
COMMIT;
SET gtid_next='AUTOMATIC';

    注意： 跳过 GTID 是一种非常危险的操作，只有在非常清楚自己在做什么的情况下才能使用。通常用于修复复制错误，例如主库上执行了一个错误的事务，需要跳过该事务的复制。

  • 设置 GTID_NEXT 为一个特定的 GTID：

    SET GTID_NEXT = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:N';

    这允许你手动指定下一个事务的 GTID。 通常用于调试或特定的维护任务。 使用后，务必将其重置为 AUTOMATIC。

10. 总结：GTID 是现代复制的基石

GTID 模式通过使用全局唯一的逻辑标识符来标识事务，彻底解决了传统复制模式存在的问题，显著提升了复制的稳定性和易用性。它简化了复制配置，实现了自动故障转移，避免了数据不一致，支持更灵活的复制拓扑，是现代 MySQL 复制的基石。 掌握 GTID 的原理和使用方法，对于管理和维护 MySQL 数据库至关重要。理解了 GTID，也就理解了 MySQL 复制的现在和未来。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注