MySQL的GTID：在多源复制（Multi-source replication）下的高级应用 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

MySQL GTID：在多源复制下的高级应用

各位好，今天我们来深入探讨MySQL的GTID（Global Transaction Identifier）在多源复制（Multi-source Replication）场景下的高级应用。GTID的引入极大地简化了复制配置和管理，尤其是在复杂拓扑结构中，其优势更为明显。多源复制允许一个Slave服务器同时从多个Master服务器接收数据，这为数据整合、分片合并、备份等应用场景提供了极大的灵活性。

1. GTID基础回顾

在深入多源复制之前，我们先简单回顾一下GTID的核心概念：

GTID: 全局事务标识符，每个在Master服务器上提交的事务都会被分配一个唯一的GTID。
GTID格式: source_id:transaction_id，例如 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-10 表示源服务器 UUID 为 3E11FA47-71CA-11E1-9E33-C80AA9429562，事务 ID 从 1 到 10。
gtid_mode: 控制GTID模式的启用和强制执行。
- OFF: 禁用GTID。
- ON: 启用GTID，允许非GTID事务。
- ON_PERMISSIVE: 启用GTID，允许非GTID事务，并发出警告。
- OFF_PERMISSIVE: 禁用GTID，允许GTID事务，并发出警告。
- OFF_MANDATORY: 禁用GTID，不允许GTID事务。
- ON_MANDATORY: 启用GTID，强制所有事务必须是GTID事务。
enforce_gtid_consistency: 强制GTID一致性。启用后，MySQL 会阻止可能导致数据不一致的操作，如在没有GTID的BINLOG中执行CREATE TEMPORARY TABLE。

2. 多源复制的场景与优势

多源复制是指一个Slave服务器可以同时连接到多个Master服务器，并从这些Master服务器接收数据更新。这种架构适用于以下场景：

数据整合: 将来自多个数据源的数据汇集到单个Slave服务器上，用于报表分析、数据仓库等。
分片合并: 将多个分片数据库的数据合并到单个Slave服务器上，用于查询优化或数据迁移。
备份与灾难恢复: 从多个Master服务器备份数据，提高数据冗余性和可用性。
数据迁移: 从多个旧的Master服务器迁移数据到新的Slave服务器。

相比于传统的单源复制，多源复制的优势在于：

灵活性: 可以灵活地从多个数据源接收数据，适应不同的业务需求。
可扩展性: 可以通过增加Master服务器来扩展数据处理能力。
高可用性: 即使某个Master服务器发生故障，Slave服务器仍然可以从其他Master服务器接收数据。

3. 多源复制的配置步骤

配置多源复制需要以下步骤：

3.1 环境准备

假设我们有三个MySQL服务器：

Master1 (192.168.1.101): 数据源1
Master2 (192.168.1.102): 数据源2
Slave (192.168.1.103): 接收来自 Master1 和 Master2 的数据

3.2 配置 Master 服务器

在 Master1 和 Master2 上，需要启用二进制日志（Binary Log）和 GTID。

-- 在 Master1 (192.168.1.101) 上执行
SET GLOBAL log_bin = ON;
SET GLOBAL server_id = 1; -- 确保 server_id 唯一
SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;
-- 重启 MySQL 服务以使配置生效

-- 在 Master2 (192.168.1.102) 上执行
SET GLOBAL log_bin = ON;
SET GLOBAL server_id = 2; -- 确保 server_id 唯一
SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;
-- 重启 MySQL 服务以使配置生效

注意: server_id 在整个复制拓扑中必须是唯一的。

3.3 创建复制用户

在 Master1 和 Master2 上创建用于复制的用户，并授权 REPLICATION SLAVE 权限。

-- 在 Master1 (192.168.1.101) 上执行
CREATE USER 'repl'@'192.168.1.103' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.103';
FLUSH PRIVILEGES;

-- 在 Master2 (192.168.1.102) 上执行
CREATE USER 'repl'@'192.168.1.103' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.103';
FLUSH PRIVILEGES;

3.4 配置 Slave 服务器

在 Slave 服务器上，启用 GTID 并配置多个复制通道。

-- 在 Slave (192.168.1.103) 上执行
SET GLOBAL gtid_mode = ON;
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL server_id = 3; -- 确保 server_id 唯一
-- 重启 MySQL 服务以使配置生效

3.5 创建复制通道

在 Slave 服务器上，使用 CHANGE MASTER TO 命令创建和配置复制通道。每个Master服务器都需要一个单独的通道。

-- 在 Slave (192.168.1.103) 上执行
-- 配置 Master1 的复制通道
CHANGE MASTER 'master1' TO
  MASTER_HOST = '192.168.1.101',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'password',
  MASTER_AUTO_POSITION = 1,
  GET_MASTER_PUBLIC_KEY = 1; -- 如果启用了TLS，需要设置

-- 配置 Master2 的复制通道
CHANGE MASTER 'master2' TO
  MASTER_HOST = '192.168.1.102',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'password',
  MASTER_AUTO_POSITION = 1,
  GET_MASTER_PUBLIC_KEY = 1; -- 如果启用了TLS，需要设置

注意:

MASTER_AUTO_POSITION = 1 启用基于 GTID 的自动定位。
GET_MASTER_PUBLIC_KEY = 1 用于启用 TLS 加密连接，如果 Master 服务器配置了 TLS，则需要设置。

3.6 启动复制通道

启动各个复制通道。

-- 在 Slave (192.168.1.103) 上执行
START SLAVE 'master1';
START SLAVE 'master2';

3.7 检查复制状态

使用 SHOW SLAVE STATUS 命令检查复制状态。

-- 在 Slave (192.168.1.103) 上执行
SHOW SLAVE STATUS FOR CHANNEL 'master1'G
SHOW SLAVE STATUS FOR CHANNEL 'master2'G

检查 Slave_IO_State, Slave_SQL_Running, Last_IO_Error, Last_SQL_Error 等字段，确保复制正常运行。

4. GTID 在多源复制中的优势

GTID 在多源复制中提供了以下优势：

自动定位: MASTER_AUTO_POSITION = 1 允许 Slave 服务器自动找到正确的复制起点，无需手动指定 BINLOG 文件和位置。
故障转移简化: 当某个 Master 服务器发生故障时，Slave 服务器可以更容易地切换到其他 Master 服务器，而无需担心 BINLOG 文件和位置的同步问题。
数据一致性: GTID 确保了事务的全局唯一性，避免了由于 BINLOG 文件和位置不一致导致的数据冲突。

5. 解决多源复制中的常见问题

在多源复制中，可能会遇到以下问题：

自增主键冲突: 如果多个 Master 服务器都使用相同的自增主键范围，可能会导致主键冲突。
- 解决方法: 为每个 Master 服务器分配不同的自增主键范围。例如，Master1 使用 1-10000，Master2 使用 10001-20000。可以通过设置 auto_increment_increment 和 auto_increment_offset 来实现。
```
-- 在 Master1 (192.168.1.101) 上执行
SET GLOBAL auto_increment_increment = 2;
SET GLOBAL auto_increment_offset = 1;

-- 在 Master2 (192.168.1.102) 上执行
SET GLOBAL auto_increment_increment = 2;
SET GLOBAL auto_increment_offset = 2;
```
DDL语句冲突: 如果多个 Master 服务器同时执行相同的 DDL 语句，可能会导致冲突。
- 解决方法: 协调 DDL 语句的执行，确保同一时刻只有一个 Master 服务器执行 DDL 语句。可以使用锁机制或人工协调。
网络延迟: 如果 Master 服务器和 Slave 服务器之间的网络延迟较高，可能会导致复制延迟。
- 解决方法: 优化网络连接，使用更快的网络设备，或者调整 MySQL 的复制参数，如 slave_net_timeout。
数据不一致: 即使启用了 GTID，仍然可能由于人为错误或程序 BUG 导致数据不一致。
- 解决方法: 定期进行数据校验，使用 pt-table-sync 等工具进行数据同步。

6. 高级应用：基于GTID的数据过滤

在某些场景下，我们可能需要只复制来自某个 Master 服务器的特定数据库或表。虽然MySQL本身并没有直接提供基于GTID的过滤功能，但我们可以结合BINLOG过滤规则和GTID来实现类似的效果。

例如，我们只想从Master1复制db1数据库，从Master2复制db2数据库。

在 Master1 上，使用 binlog_do_db 参数限制只记录 db1 数据库的更改。 注意：不推荐使用binlog_do_db，因为它会影响其他复制场景。更好的做法是在应用程序层面控制写入哪个数据库。

-- 不推荐，仅作为示例
-- 在 Master1 (192.168.1.101) 上执行
-- 修改 my.cnf 文件，添加或修改以下行
[mysqld]
binlog_do_db = db1
-- 重启 MySQL 服务

在 Master2 上，使用 binlog_do_db 参数限制只记录 db2 数据库的更改。

-- 不推荐，仅作为示例
-- 在 Master2 (192.168.1.102) 上执行
-- 修改 my.cnf 文件，添加或修改以下行
[mysqld]
binlog_do_db = db2
-- 重启 MySQL 服务

更推荐的做法: 在应用程序层面控制写入哪个数据库。如果必须使用BINLOG过滤，则应该结合GTID的gtid_executed集合来处理。但是，这会引入额外的复杂性，需要编写脚本来分析GTID集合，并根据GTID的来源数据库来决定是否应用。

7. 使用 gtid_executed 集合管理复制

gtid_executed 是一个服务器变量，用于存储服务器已经执行过的 GTID 集合。我们可以利用这个集合来跳过或重放特定的事务。

例如，如果 Slave 服务器在复制 Master1 的过程中出现错误，导致某些事务没有被正确执行，我们可以使用以下步骤来修复：

停止 Master1 的复制通道。

-- 在 Slave (192.168.1.103) 上执行
STOP SLAVE 'master1';

找到 Slave 服务器上没有执行的 GTID。 比较 Master1 的 gtid_executed 和 Slave 服务器上 Master1 通道的 gtid_executed。

-- 在 Master1 (192.168.1.101) 上执行
SHOW GLOBAL STATUS LIKE 'Gtid_executed';

-- 在 Slave (192.168.1.103) 上执行
SHOW GLOBAL STATUS LIKE 'Gtid_executed'; -- 注意: 这显示的是所有通道的总和
SELECT @@gtid_executed; -- 或者使用这个查询

使用 SET gtid_next 和 BEGIN ... COMMIT 语句来跳过或重放这些事务。
- 跳过事务:
```
-- 在 Slave (192.168.1.103) 上执行
SET gtid_next = '3E11FA47-71CA-11E1-9E33-C80AA9429562:101'; -- 替换为要跳过的 GTID
BEGIN;
COMMIT;
SET gtid_next = AUTOMATIC;
```
- 重放事务: 如果 BINLOG 文件仍然可用，可以手动从 BINLOG 文件中提取事务并执行。
启动 Master1 的复制通道。

-- 在 Slave (192.168.1.103) 上执行
START SLAVE 'master1';

8. 多源复制的监控与维护

对于多源复制的监控，主要关注以下几个方面：

复制延迟: 使用 SHOW SLAVE STATUS 命令检查 Seconds_Behind_Master 字段。
错误日志: 检查 MySQL 的错误日志，查看是否有复制相关的错误信息。
资源使用情况: 监控 Slave 服务器的 CPU、内存、磁盘 I/O 等资源使用情况，确保服务器性能足够。
数据一致性: 定期进行数据校验，确保 Slave 服务器上的数据与 Master 服务器上的数据一致。

对于多源复制的维护，主要包括以下几个方面：

定期备份: 定期备份 Slave 服务器上的数据，以防止数据丢失。
升级 MySQL 版本: 升级 MySQL 版本时，需要仔细阅读官方文档，了解升级过程中的注意事项。
监控复制状态: 使用监控工具定期检查复制状态，及时发现并解决问题。

9. 总结： GTID在多源复制中简化管理，提升可靠性

GTID在MySQL多源复制中扮演着至关重要的角色，它简化了复制配置、故障转移和数据一致性维护。通过合理配置和监控，可以构建稳定可靠的多源复制架构，满足复杂的数据整合、备份和灾难恢复需求。

MySQL GTID：在多源复制下的高级应用

发表回复 取消回复

发表回复取消回复