`MySQL`的`多源`复制：`一个`从`库`复制`多个`主`库`的`配置`与`实践`。

MySQL 多源复制：配置与实践

各位同学，大家好。今天我们来聊聊 MySQL 的一个高级特性：多源复制。在标准的 MySQL 复制架构中，一个从库只能从一个主库进行数据同步。但在某些复杂场景下，我们需要一个从库同时从多个主库复制数据，这就是多源复制。

为什么需要多源复制？

多源复制的应用场景主要集中在以下几个方面：

1. 数据聚合/合并： 多个业务系统，每个系统有自己的 MySQL 主库，我们需要将这些数据集中到一个地方做报表分析或者数据仓库。
2. 数据分片/合并： 将数据库按照某种规则分片到多个主库上，然后将这些分片数据合并到一个从库上。
3. 备份/灾备： 从多个主库进行备份，提高数据安全性。
4. 异构数据同步： 即使不同主库的数据结构略有不同，也可以通过适当配置在从库进行整合（需要复杂的变换逻辑）。

多源复制原理

MySQL 的多源复制依赖于以下几个关键特性：

1. GTID (Global Transaction ID): GTID 是一个全局唯一的事务 ID，用于在复制拓扑中唯一标识一个事务。多源复制依赖 GTID 来跟踪每个主库的复制进度。
2. Replication Channels: 复制通道是 MySQL 8.0 引入的概念，允许一个从库配置多个复制通道，每个通道对应一个主库。每个通道都有独立的复制线程和 Relay Log。
3. Relay Log: 从库会为每个复制通道维护一个 Relay Log，用于存储从对应主库接收到的二进制日志事件。
4. 复制过滤器： 通过复制过滤器，我们可以控制从哪些主库复制哪些数据库或者表。

配置多源复制

现在我们来一步步配置一个多源复制的示例。假设我们有两个主库：master1 和 master2，以及一个从库 slave。

1. 环境准备

首先，我们需要准备三台 MySQL 服务器。以下是示例配置：

服务器	IP 地址	端口	MySQL 版本	GTID 模式
master1	192.168.1.1	3306	8.0	ON
master2	192.168.1.2	3306	8.0	ON
slave	192.168.1.3	3306	8.0	ON

2. 主库配置

对于 master1 和 master2，我们需要确保它们启用 GTID，并配置 server-id。

• master1 (192.168.1.1):

-- /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_format = ROW
enforce_gtid_consistency = ON
gtid_mode = ON
relay_log = relay-log

• master2 (192.168.1.2):

-- /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
server-id = 2
log_bin = mysql-bin
binlog_format = ROW
enforce_gtid_consistency = ON
gtid_mode = ON
relay_log = relay-log

修改配置文件后，重启 MySQL 服务。

sudo systemctl restart mysql

3. 从库配置

在 slave (192.168.1.3) 上，我们需要配置 server-id，并启用 GTID。

-- /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
server-id = 3
log_bin = mysql-bin
binlog_format = ROW
enforce_gtid_consistency = ON
gtid_mode = ON
relay_log = relay-log

修改配置文件后，重启 MySQL 服务。

sudo systemctl restart mysql

4. 创建复制用户

在 master1 和 master2 上，我们需要创建具有 REPLICATION SLAVE 权限的复制用户。

• master1 (192.168.1.1):

CREATE USER 'repl'@'192.168.1.3' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.3';
FLUSH PRIVILEGES;

• master2 (192.168.1.2):

CREATE USER 'repl'@'192.168.1.3' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.3';
FLUSH PRIVILEGES;

5. 配置复制通道

在 slave (192.168.1.3) 上，我们需要配置两个复制通道，分别对应 master1 和 master2。

• 配置 master1 的复制通道:

STOP SLAVE;
RESET SLAVE ALL; -- 清理之前的复制信息，如果之前有配置的话
CHANGE MASTER 'master1' TO
  MASTER_HOST='192.168.1.1',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_AUTO_POSITION=1;  -- 使用 GTID 自动定位
START SLAVE 'master1';

SHOW SLAVE STATUS FOR CHANNEL 'master1'G

• 配置 master2 的复制通道:

STOP SLAVE;  -- 停止所有通道。  注意，此时'master1'通道也会停止。
RESET SLAVE ALL; -- 再次清理之前的复制信息，确保干净。
CHANGE MASTER 'master2' TO
  MASTER_HOST='192.168.1.2',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_AUTO_POSITION=1;  -- 使用 GTID 自动定位
START SLAVE 'master2';

SHOW SLAVE STATUS FOR CHANNEL 'master2'G

注意: CHANGE MASTER 命令中的 'master1' 和 'master2' 实际上是复制通道的名称，可以自定义。MASTER_AUTO_POSITION=1 表示使用 GTID 自动定位复制位置。

重要提示: 在配置多源复制的时候，如果之前从库已经配置过复制，需要使用 RESET SLAVE ALL 清理之前的复制信息。 并且，在配置第二个通道之前，必须先停止所有通道 (STOP SLAVE;)，否则会报错。

6. 启动所有通道

配置完成后，我们需要启动所有复制通道。

START SLAVE; -- 启动所有通道

7. 验证复制状态

使用以下命令可以查看每个复制通道的状态：

SHOW SLAVE STATUS FOR CHANNEL 'master1'G
SHOW SLAVE STATUS FOR CHANNEL 'master2'G

检查 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes。如果都为 Yes，表示复制通道正常运行。

8. 复制过滤器 (可选)

如果需要从不同的主库复制不同的数据库或表，可以使用复制过滤器。例如，只从 master1 复制 db1 数据库，只从 master2 复制 db2 数据库。

• 配置 master1 的复制通道:

STOP SLAVE 'master1';
CHANGE MASTER 'master1' TO
  MASTER_HOST='192.168.1.1',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_AUTO_POSITION=1,
  REPLICATE_DO_DB=('db1'); -- 只复制 db1 数据库
START SLAVE 'master1';

• 配置 master2 的复制通道:

STOP SLAVE 'master2';
CHANGE MASTER 'master2' TO
  MASTER_HOST='192.168.1.2',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_AUTO_POSITION=1,
  REPLICATE_DO_DB=('db2'); -- 只复制 db2 数据库
START SLAVE 'master2';

常用的复制过滤器参数：

参数	描述
REPLICATE_DO_DB	指定要复制的数据库列表。
REPLICATE_IGNORE_DB	指定要忽略的数据库列表。
REPLICATE_DO_TABLE	指定要复制的表列表，格式为 database.table。
REPLICATE_IGNORE_TABLE	指定要忽略的表列表，格式为 database.table。
REPLICATE_WILD_DO_TABLE	使用通配符指定要复制的表列表，例如 db%.t%。
REPLICATE_WILD_IGNORE_TABLE	使用通配符指定要忽略的表列表，例如 db%.t%。

9. 测试多源复制

在 master1 的 db1 数据库中创建一个表并插入数据：

-- master1 (192.168.1.1)
CREATE DATABASE IF NOT EXISTS db1;
USE db1;
CREATE TABLE t1 (id INT PRIMARY KEY);
INSERT INTO t1 VALUES (1);

在 master2 的 db2 数据库中创建一个表并插入数据：

-- master2 (192.168.1.2)
CREATE DATABASE IF NOT EXISTS db2;
USE db2;
CREATE TABLE t2 (id INT PRIMARY KEY);
INSERT INTO t2 VALUES (2);

在 slave 上验证数据是否同步成功：

-- slave (192.168.1.3)
USE db1;
SELECT * FROM t1; -- 应该能看到 id=1 的数据

USE db2;
SELECT * FROM t2; -- 应该能看到 id=2 的数据

如果在 slave 上能看到来自 master1 和 master2 的数据，说明多源复制配置成功。

多源复制的管理与维护

多源复制配置完成后，我们需要定期监控复制状态，并处理可能出现的问题。

1. 监控复制状态

使用 SHOW SLAVE STATUS FOR CHANNEL 命令可以查看每个复制通道的状态。我们需要关注以下几个关键指标：

• Slave_IO_Running: 复制 I/O 线程是否正在运行。
• Slave_SQL_Running: 复制 SQL 线程是否正在运行。
• Last_IO_Error: 最近一次 I/O 线程的错误信息。
• Last_SQL_Error: 最近一次 SQL 线程的错误信息。
• Seconds_Behind_Master: 从库延迟的时间，单位为秒。

2. 处理复制错误

常见的复制错误包括：

• 网络问题： 从库无法连接到主库。
• 权限问题： 复制用户没有足够的权限。
• 数据不一致： 主库和从库的数据不一致。
• GTID 问题： GTID 冲突或者 GTID 丢失。

针对不同的错误，我们需要采取不同的处理措施。例如，如果是网络问题，需要检查网络连接；如果是权限问题，需要检查复制用户的权限；如果是数据不一致，需要修复数据。

3. 复制延迟

复制延迟是多源复制中常见的问题。复制延迟可能由多种原因引起，例如：

• 主库负载过高： 主库处理事务的速度太慢。
• 从库负载过高： 从库应用 Relay Log 的速度太慢。
• 网络延迟： 网络传输速度慢。
• 大事务： 单个事务包含大量数据。

针对不同的原因，我们可以采取不同的优化措施。例如，可以优化主库和从库的性能，可以优化网络，可以避免大事务。

4. 切换主库

在多源复制环境中，切换主库相对复杂。我们需要停止所有复制通道，然后修改复制通道的配置，最后启动复制通道。

5. 故障恢复

如果主库发生故障，我们需要手动切换到备库。在切换之前，我们需要确保从库已经同步了所有数据。

多源复制的局限性

多源复制也存在一些局限性：

1. 配置复杂： 多源复制的配置相对复杂，需要仔细规划和配置。
2. 维护困难： 多源复制的维护也相对困难，需要定期监控复制状态，并处理可能出现的问题。
3. 数据冲突： 如果多个主库同时修改同一行数据，可能会导致数据冲突。需要避免这种情况的发生，或者使用冲突解决机制。
4. 性能影响： 从库需要处理来自多个主库的数据，可能会对从库的性能产生影响。

多源复制的替代方案

如果多源复制的局限性无法接受，可以考虑使用其他替代方案，例如：

1. ETL (Extract, Transform, Load): 使用 ETL 工具将数据从多个主库抽取到数据仓库中。
2. 消息队列： 使用消息队列将数据从多个主库发送到消费者。
3. 数据库中间件： 使用数据库中间件将多个主库的数据聚合到一个虚拟数据库中。

选择哪种方案取决于具体的应用场景和需求。

代码示例：监控复制状态的脚本

以下是一个简单的 Python 脚本，用于监控多源复制的状态。

import mysql.connector

def get_slave_status(channel):
    try:
        mydb = mysql.connector.connect(
            host="192.168.1.3",  # 从库的 IP 地址
            user="root",
            password="password",
            database="mysql"
        )
        mycursor = mydb.cursor(dictionary=True)

        query = "SHOW SLAVE STATUS FOR CHANNEL '{}'".format(channel)
        mycursor.execute(query)
        result = mycursor.fetchone()

        mydb.close()

        if result:
            return result
        else:
            return None

    except mysql.connector.Error as err:
        print("Error: {}".format(err))
        return None

if __name__ == '__main__':
    channels = ['master1', 'master2']  # 复制通道的名称

    for channel in channels:
        status = get_slave_status(channel)

        if status:
            print("Channel: {}".format(channel))
            print("  Slave_IO_Running: {}".format(status['Slave_IO_Running']))
            print("  Slave_SQL_Running: {}".format(status['Slave_SQL_Running']))
            print("  Seconds_Behind_Master: {}".format(status['Seconds_Behind_Master']))
            print("----------------------")
        else:
            print("Could not get slave status for channel: {}".format(channel))

这个脚本连接到从库，执行 SHOW SLAVE STATUS FOR CHANNEL 命令，并打印出关键的复制状态信息。

多源复制的未来展望

随着云计算和微服务架构的普及，多源复制的应用场景将会越来越多。未来，MySQL 将会继续改进多源复制的功能，例如：

• 更强大的复制过滤器： 允许更灵活地控制从哪些主库复制哪些数据。
• 更智能的冲突解决机制： 自动解决数据冲突，减少人工干预。
• 更易用的管理工具： 提供更方便的管理工具，简化多源复制的配置和维护。

总结

今天，我们详细介绍了 MySQL 多源复制的原理、配置、管理和局限性。希望通过今天的讲解，大家能够对 MySQL 多源复制有一个更深入的了解，并能够在实际工作中灵活运用。 掌握配置流程，关注关键状态，结合实际场景进行调整。

实践是检验真理的唯一标准

实际操作才能真正理解多源复制的复杂性，配置过程中遇到的问题需要耐心解决。

持续学习，不断进步

MySQL 技术不断发展，需要持续学习新的知识，才能更好地应对未来的挑战。