MySQL基于GTID的复制配置与实现

MariaDB 与 MySQL 的关系及 GTID 简介

MariaDB 是 MySQL 数据库管理系统的一个分支，由 MySQL 的原开发者主导开发，旨在继续保持开源和社区驱动的发展模式。GTID（Global Transaction Identifier）即全局事务标识符，它是一个在整个复制拓扑中唯一标识每个事务的编号。在传统的 MySQL 复制中，基于日志文件位置（binlog 文件名和偏移量）来标识主从复制的同步点，这种方式在主库切换或故障恢复时可能会变得复杂。而 GTID 提供了一种更简单、可靠的方式来管理复制，每个事务都有一个唯一的 GTID，从库可以通过 GTID 准确地找到并应用主库上发生的事务。

MySQL 基于 GTID 的复制原理

1. GTID 的组成 GTID 由两部分组成：源 UUID 和事务编号。源 UUID 是主库的唯一标识符，在 MySQL 启动时生成，事务编号则是主库上每个事务的递增编号。例如，5e866f1b-7c2a-11e9-908a-000c29c3c932:1，其中 5e866f1b-7c2a-11e9-908a-000c29c3c932 是源 UUID，1 是事务编号。
2. 复制过程
   • 主库：当主库上执行一个事务时，它会在二进制日志（binlog）中记录该事务，并为其分配一个 GTID。这个 GTID 会随着事务的日志记录一起写入 binlog。
   • 从库：从库通过 I/O 线程连接到主库，读取主库的 binlog 并将其写入自己的中继日志（relay log）。SQL 线程则从中继日志中读取事务，并根据 GTID 判断是否已经应用过该事务。如果没有应用过，SQL 线程就会应用该事务，从而保持与主库的数据同步。

配置基于 GTID 的 MySQL 复制环境准备

1. 操作系统与软件版本 本文以 CentOS 7 作为操作系统，MySQL 8.0 版本为例进行配置。确保服务器之间网络畅通，并且具备相应的安装和配置权限。
2. MySQL 安装 可以通过官方 Yum 仓库安装 MySQL：

# 下载并安装 MySQL Yum 仓库配置文件
wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
rpm -ivh mysql80-community-release-el7-3.noarch.rpm

# 安装 MySQL 服务器
yum install mysql-community-server

安装完成后，启动 MySQL 服务并设置开机自启：

systemctl start mysqld
systemctl enable mysqld

3. 获取初始密码并登录 MySQL 8.0 安装后，会在日志文件中生成一个初始密码。可以通过以下命令获取：

grep 'temporary password' /var/log/mysqld.log

然后使用该初始密码登录 MySQL：

mysql -uroot -p

登录后，修改 root 用户密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';

主库配置

1. 修改主库配置文件 编辑 MySQL 主库的配置文件，一般为 /etc/my.cnf：

[mysqld]
# 开启二进制日志
log-bin=mysql-bin
# 设置服务器唯一 ID，不同服务器 ID 必须不同
server-id=1
# 开启 GTID 模式
gtid_mode=ON
enforce_gtid_consistency=ON

保存并退出配置文件后，重启 MySQL 服务使配置生效：

systemctl restart mysqld

2. 创建用于复制的用户 登录主库 MySQL，创建一个用于从库连接复制的用户：

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

3. 查看主库状态 执行以下命令查看主库状态，获取用于从库配置的信息：

SHOW MASTER STATUS;

输出结果类似如下：

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      154 |              |                  | 5e866f1b-7c2a-11e9-908a-000c29c3c932:1-2 |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

记录下 File 和 Position 的值，以及 Executed_Gtid_Set 的值，后续从库配置会用到。

从库配置

1. 修改从库配置文件 同样编辑从库的 MySQL 配置文件 /etc/my.cnf：

[mysqld]
# 设置服务器唯一 ID，必须与主库不同
server-id=2
# 开启 GTID 模式
gtid_mode=ON
enforce_gtid_consistency=ON

保存并重启 MySQL 服务：

systemctl restart mysqld

2. 配置从库连接主库 登录从库 MySQL，使用以下命令配置从库连接主库：

CHANGE MASTER TO
    MASTER_HOST='主库 IP 地址',
    MASTER_USER='replication_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000003', # 主库 SHOW MASTER STATUS 中的 File 值
    MASTER_LOG_POS=154, # 主库 SHOW MASTER STATUS 中的 Position 值
    MASTER_AUTO_POSITION=1;

3. 启动从库复制并查看状态 启动从库复制：

START SLAVE;

查看从库状态：

SHOW SLAVE STATUS \G;

重点关注以下两个参数： - Slave_IO_Running 和 Slave_SQL_Running 都应该为 Yes，表示 I/O 线程和 SQL 线程都在正常运行。 - Seconds_Behind_Master 如果为 0，表示从库与主库数据同步正常，没有延迟。

基于 GTID 的复制验证与故障处理

1. 数据验证 在主库上创建一个测试数据库和表，并插入数据：

CREATE DATABASE test;
USE test;
CREATE TABLE users (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));
INSERT INTO users (name) VALUES ('Alice'), ('Bob');

然后在从库上检查是否能看到相同的数据：

USE test;
SELECT * FROM users;

如果能看到相同的数据，则说明基于 GTID 的复制配置成功。 2. 主库故障处理 假设主库发生故障，需要将从库提升为主库。首先在当前从库上执行：

STOP SLAVE;
RESET MASTER;

然后修改配置文件，将 server-id 设置为新的唯一值（如果需要），并重启 MySQL 服务。其他从库则需要重新配置连接到这个新的主库：

CHANGE MASTER TO
    MASTER_HOST='新主库 IP 地址',
    MASTER_USER='replication_user',
    MASTER_PASSWORD='password',
    MASTER_AUTO_POSITION=1;
START SLAVE;

3. 从库故障处理 如果从库发生故障，重启从库 MySQL 服务后，检查从库状态：

SHOW SLAVE STATUS \G;

如果发现复制状态异常，可以尝试重新启动复制：

STOP SLAVE;
START SLAVE;

如果问题仍然存在，可能需要重新配置从库连接主库，按照从库配置的步骤重新进行设置。

GTID 模式下的复制优化

1. 多线程复制 MySQL 从 5.6 版本开始支持多线程复制。在 GTID 模式下，可以进一步优化复制性能。编辑从库配置文件，添加以下配置：

[mysqld]
# 开启多线程复制
slave_parallel_workers=4
slave_parallel_type=LOGICAL_CLOCK

重启 MySQL 服务后，从库会使用多个线程并行应用中继日志中的事务，提高复制效率。 2. 优化 binlog 写入 在主库上，可以通过调整 binlog 相关参数来优化写入性能。例如，设置合适的 binlog_cache_size 和 max_binlog_cache_size：

[mysqld]
binlog_cache_size=64K
max_binlog_cache_size=1G

这些参数控制着事务在内存中缓存 binlog 的大小，合理设置可以减少磁盘 I/O 操作，提高主库性能。 3. 网络优化 确保主从服务器之间的网络带宽充足，并且网络延迟较低。可以通过调整网络参数，如 tcp_buffer_size 等，来优化网络传输性能。例如，在 /etc/sysctl.conf 文件中添加：

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

然后执行 sysctl -p 使配置生效。

GTID 复制的常见问题及解决方法

1. 复制延迟
   • 原因：可能是主库负载过高，导致事务生成速度快于从库应用速度；从库硬件性能不足，如磁盘 I/O 慢或 CPU 使用率高；网络延迟大等。
   • 解决方法：优化主库性能，减少不必要的查询和事务；升级从库硬件；优化网络；开启多线程复制。
2. GTID 不一致
   • 原因：在 GTID 模式下进行了不支持的操作，如手动修改 binlog 文件或在主从库之间进行非 GTID 方式的数据同步。
   • 解决方法：停止复制，重置主从库的 GTID 状态，重新配置复制。具体步骤为，在主库执行 RESET MASTER，在从库执行 STOP SLAVE、RESET SLAVE ALL，然后重新按照配置步骤设置从库连接主库。
3. 从库 I/O 线程或 SQL 线程异常停止
   • 原因：可能是网络连接中断、主库配置变更、权限问题等。
   • 解决方法：检查网络连接；确认主库配置是否有变更并相应调整从库；检查从库复制用户权限是否足够。如果是网络问题导致 I/O 线程停止，可以尝试重新启动从库复制。如果是权限问题，重新授予正确的权限。

基于 GTID 复制的高可用方案集成

1. MHA（Master High Availability） MHA 是一个常用的 MySQL 高可用解决方案，可以与基于 GTID 的复制集成。
   • 安装 MHA 软件：在所有节点上安装 MHA 相关软件包，包括 mha4mysql-manager 和 mha4mysql-node。
   • 配置 MHA：编辑 MHA 配置文件，指定主从服务器信息、复制用户等。例如：

[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/var/lib/mysql
user=root
password=root_password
ping_interval=2
repl_user=replication_user
repl_password=password

[server1]
hostname=主库 IP 地址
candidate_master=1
check_repl_delay=0

[server2]
hostname=从库 1 IP 地址

[server3]
hostname=从库 2 IP 地址

- **启动 MHA**：使用 `masterha_manager` 命令启动 MHA 管理进程，监控主从复制状态。当主库发生故障时，MHA 会自动将一个从库提升为主库，并调整其他从库连接到新主库。

2. Orchestrator Orchestrator 也是一个用于 MySQL 复制管理和高可用的工具。 - 安装 Orchestrator：下载并安装 Orchestrator 二进制文件。 - 配置 Orchestrator：编辑配置文件，设置数据库连接信息、复制拓扑发现规则等。例如：

MySQLTopology:
  OrchestratorMySQLOverrideSource:
    username: root
    password: root_password
  OrchestratorReplicationUseGTID: true
  OrchestratorReplicationTopologyMode: auto
  OrchestratorReplicationAutoDetect: true

- **启动 Orchestrator**：启动 Orchestrator 服务，通过 Web 界面或 API 管理 MySQL 复制拓扑，实现自动故障转移和拓扑调整。

基于 GTID 复制的性能监控与调优

1. 性能监控工具
   • MySQL Enterprise Monitor：这是 MySQL 官方提供的监控工具，可以实时监控主从库的性能指标，如 CPU 使用率、磁盘 I/O、复制延迟等。它还提供性能分析报告和预警功能。
   • Percona Toolkit：包含一系列命令行工具，如 pt - query - digest 可以分析查询日志，找出慢查询；pt - table - checksum 可以检查主从库数据一致性。
2. 性能调优指标
   • 复制延迟：通过 SHOW SLAVE STATUS 中的 Seconds_Behind_Master 字段监控。如果延迟过高，分析主库负载、从库硬件和网络等因素进行优化。
   • 查询性能：使用 EXPLAIN 关键字分析查询语句的执行计划，优化索引使用。对于频繁执行的查询，可以考虑使用查询缓存。
   • binlog 和 relay log 大小：定期清理过期的 binlog 和 relay log 文件，避免占用过多磁盘空间。可以通过设置 expire_logs_days 参数控制 binlog 文件的保留天数。
3. 负载均衡 在主从复制环境中，可以使用负载均衡器将读请求分发到从库，减轻主库压力。常见的负载均衡器有 HAProxy、Nginx 等。以 HAProxy 为例，配置如下：

frontend mysql - frontend
    bind *:3306
    mode tcp
    default_backend mysql - backend

backend mysql - backend
    mode tcp
    balance roundrobin
    server slave1 从库 1 IP 地址:3306 check
    server slave2 从库 2 IP 地址:3306 check

这样，客户端的读请求会被均匀分配到各个从库上，提高系统的整体性能。

通过以上详细的配置、验证、优化及故障处理等步骤，可以有效地实现和管理基于 GTID 的 MySQL 复制，确保数据库系统的高可用性、数据一致性和性能。在实际生产环境中，还需要根据具体的业务需求和系统规模进行进一步的调整和优化。