MariaDB基于GTID的复制配置详解

MariaDB 基于 GTID 的复制配置详解

1. GTID 简介

在深入了解 MariaDB 基于 GTID 的复制配置之前，我们先来认识一下 GTID（Global Transaction Identifier，全局事务标识符）。GTID 是 MariaDB 和 MySQL 5.6 及以上版本引入的一项重要特性，它为每个在主库上提交的事务分配一个全局唯一的标识符。

GTID 由两部分组成：源标识符（source identifier）和事务编号（transaction number）。源标识符通常是主库的 UUID（Universally Unique Identifier），事务编号则是该主库上的事务序列号。这种全局唯一标识事务的方式，使得在复制环境中，从库能够更准确、高效地识别和应用主库上的事务，大大简化了复制的管理和维护。

传统的基于二进制日志（binary log）位置的复制方式存在一些局限性。例如，在主库发生故障切换时，从库需要手动指定新主库的二进制日志文件名和位置，这一过程容易出错且繁琐。而 GTID 模式下，从库可以根据 GTID 自动定位和应用事务，无需关心具体的二进制日志位置，从而提高了复制的可靠性和自动化程度。

2. 环境准备

在进行 MariaDB 基于 GTID 的复制配置之前，我们需要准备好合适的环境。以下是环境准备的具体步骤：

• 操作系统：本次演示使用的是 CentOS 7.9 操作系统。你可以根据实际情况选择其他主流操作系统，但相关的软件安装和配置命令可能会有所不同。
• 安装 MariaDB：首先，我们需要在主库和从库上安装 MariaDB。在 CentOS 7 上，可以通过以下步骤安装 MariaDB：

  # 安装 MariaDB 仓库
  rpm -Uvh http://yum.mariadb.org/10.5/rhel7-amd64/mariadb-10.5.13-centos7-amd64.rpm
  # 安装 MariaDB 服务器
  yum install mariadb-server
  # 启动 MariaDB 服务
  systemctl start mariadb
  # 设置 MariaDB 开机自启
  systemctl enable mariadb
  

• 配置防火墙：如果服务器启用了防火墙，需要开放 MariaDB 服务使用的端口，默认为 3306。可以使用以下命令在防火墙中添加规则：

  firewall-cmd --zone=public --add-port=3306/tcp --permanent
  firewall-cmd --reload
  

3. 主库配置

主库的配置是基于 GTID 复制的关键步骤。以下是详细的主库配置过程：

• 编辑配置文件：打开 MariaDB 的配置文件，通常位于 /etc/my.cnf 或 /etc/mysql/my.cnf。在配置文件中添加或修改以下参数：

  [mysqld]
  # 启用 GTID
  gtid_mode=ON
  enforce_gtid_consistency=ON
  # 主库唯一标识
  server_id=1
  # 开启二进制日志
  log-bin=mysql-bin
  # 同步时忽略的数据库（可选）
  binlog-ignore-db=mysql
  binlog-ignore-db=information_schema
  binlog-ignore-db=performance_schema
  binlog-ignore-db=sys
  

  • gtid_mode=ON：启用 GTID 模式。
  • enforce_gtid_consistency=ON：确保 GTID 一致性，该参数会限制一些可能导致 GTID 不一致的操作，如使用 LOAD DATA INFILE 等非事务性语句。
  • server_id：每个参与复制的节点都必须有唯一的 server_id，这里主库设置为 1。
  • log-bin=mysql-bin：开启二进制日志，并指定二进制日志文件的前缀为 mysql-bin。
  • binlog-ignore-db：用于指定同步时忽略的数据库，这里忽略了系统自带的一些数据库，避免不必要的同步。

• 重启 MariaDB 服务：配置文件修改完成后，重启 MariaDB 服务使配置生效：

  systemctl restart mariadb
  

• 创建复制用户：登录到 MariaDB 主库，创建一个用于从库连接的复制用户：

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

  • CREATE USER 语句创建了一个名为 replication_user 的用户，并允许该用户从任何主机（%）连接，设置密码为 password。
  • GRANT REPLICATION SLAVE 授予该用户复制相关的权限。
  • FLUSH PRIVILEGES 刷新权限表使新权限生效。

4. 从库配置

从库的配置与主库类似，但也有一些不同之处。以下是从库的配置步骤：

• 编辑配置文件：在从库上打开 MariaDB 的配置文件，添加或修改以下参数：

  [mysqld]
  # 启用 GTID
  gtid_mode=ON
  enforce_gtid_consistency=ON
  # 从库唯一标识
  server_id=2
  

  • 同样启用 GTID 模式并确保 GTID 一致性。
  • server_id 设置为 2，确保与主库的 server_id 不同。

• 重启 MariaDB 服务：修改配置文件后，重启 MariaDB 服务：

  systemctl restart mariadb
  

• 配置从库连接主库：登录到 MariaDB 从库，执行以下命令配置从库连接主库：

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

  • MASTER_HOST 指定主库的 IP 地址。
  • MASTER_USER 和 MASTER_PASSWORD 是主库上创建的复制用户及其密码。
  • MASTER_AUTO_POSITION=1 表示使用 GTID 自动定位主库的日志位置。

• 启动从库复制：配置完成后，启动从库的复制进程：

  START SLAVE;
  

• 检查从库状态：可以使用以下命令检查从库的复制状态：

  SHOW SLAVE STATUS \G;
  

  重点关注以下两个参数：

  • Slave_IO_Running：表示从库的 I/O 线程是否正在运行，应该为 Yes。
  • Slave_SQL_Running：表示从库的 SQL 线程是否正在运行，也应该为 Yes。
  • Seconds_Behind_Master：表示从库落后主库的时间，理想情况下应该为 0 或非常小的值。

5. 验证复制

配置完成主库和从库后，我们需要验证复制是否正常工作。以下是验证的方法：

• 在主库创建测试数据库和表：登录到主库，执行以下 SQL 语句创建一个测试数据库和表，并插入一些数据：

  CREATE DATABASE test;
  USE test;
  CREATE TABLE test_table (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));
  INSERT INTO test_table (name) VALUES ('test1'), ('test2'), ('test3');
  

• 在从库检查数据：登录到从库，检查是否同步了主库创建的数据库、表和数据：

  SHOW DATABASES;
  USE test;
  SELECT * FROM test_table;
  

  如果能看到主库创建的 test 数据库、test_table 表以及插入的数据，说明基于 GTID 的复制配置成功。

6. 常见问题及解决方法

在配置 MariaDB 基于 GTID 的复制过程中，可能会遇到一些问题。以下是一些常见问题及解决方法：

• 从库 I/O 线程或 SQL 线程异常：如果 SHOW SLAVE STATUS \G 中 Slave_IO_Running 或 Slave_SQL_Running 为 No，可以查看错误日志（通常位于 /var/log/mariadb/mariadb.log）获取详细的错误信息。常见的原因包括网络问题、复制用户权限不足、主从库 GTID 不一致等。

  • 网络问题：检查主从库之间的网络连接是否正常，可以使用 ping 命令和 telnet 命令检查 3306 端口是否可达。
  • 权限问题：确保从库使用的复制用户在主库上具有正确的权限。可以在主库上重新授予权限并在从库上重新配置连接。
  • GTID 不一致：如果主从库的 GTID 不一致，可以尝试在从库上执行 RESET SLAVE ALL 命令，然后重新配置从库连接主库。

• 主库故障切换后从库同步异常：在主库发生故障切换后，从库可能无法自动切换到新主库。此时，可以在从库上重新配置主库连接信息，使用新主库的 IP 地址、复制用户和密码，并确保 MASTER_AUTO_POSITION=1。

7. 性能优化

为了确保基于 GTID 的复制在生产环境中高效运行，我们可以进行一些性能优化：

• 优化网络配置：确保主从库之间的网络带宽充足，减少网络延迟。可以通过调整网络设备的配置、优化网络拓扑等方式来提高网络性能。
• 调整 MariaDB 参数：根据服务器的硬件资源和业务负载，调整 MariaDB 的相关参数。例如，可以增加 innodb_buffer_pool_size 来提高 InnoDB 存储引擎的性能，适当调整 sync_binlog 参数来平衡数据安全性和性能。
• 定期清理二进制日志：主库上的二进制日志会不断增长，占用大量磁盘空间。可以定期使用 PURGE BINARY LOGS 命令清理不再需要的二进制日志。例如，保留最近 7 天的二进制日志，可以使用以下命令：

  PURGE BINARY LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY);
  

8. 总结

通过以上步骤，我们详细介绍了 MariaDB 基于 GTID 的复制配置过程，包括环境准备、主库配置、从库配置、验证复制、常见问题解决以及性能优化等方面。GTID 为 MariaDB 的复制带来了更高的可靠性和自动化程度，在生产环境中具有重要的应用价值。希望通过本文的介绍，你能够熟练掌握 MariaDB 基于 GTID 的复制配置，并应用到实际项目中。

需要注意的是，在实际生产环境中，还需要考虑数据备份、高可用性、安全性等多方面的因素，以确保数据库系统的稳定运行。同时，不同版本的 MariaDB 在配置和特性上可能会有一些细微差异，在实际操作时请参考官方文档进行准确配置。

通过以上详细的配置和优化，你可以搭建一个高效、可靠的 MariaDB 基于 GTID 的复制环境，满足业务对于数据冗余和灾备的需求。在实际应用中，还需根据业务的发展和变化，持续监控和调整复制环境的配置，以保障数据的一致性和系统的稳定性。

例如，在大型电商系统中，通过基于 GTID 的 MariaDB 复制，可以将主库上的订单数据、用户数据等实时同步到多个从库，从库可以用于数据分析、报表生成等读密集型业务，减轻主库的压力，同时保证数据的一致性和实时性。

再比如，在金融系统中，基于 GTID 的复制可以用于灾备中心的建设，当主数据中心发生故障时，灾备中心的从库能够快速接管业务，确保金融交易的连续性和数据的安全性。

总之，MariaDB 基于 GTID 的复制是一项强大的技术，合理应用可以为企业的数据库架构带来诸多优势，提升系统的整体性能和可靠性。

9. 拓展知识

9.1 GTID 与多主复制

在传统的主从复制架构中，通常只有一个主库负责写入操作。而 GTID 的出现使得多主复制变得更加可行和易于管理。

在多主复制环境下，多个节点都可以作为主库接受写入操作。每个主库都会生成自己的 GTID 集合，并且这些主库之间需要相互同步数据。配置多主复制时，除了每个节点都要启用 GTID 模式和设置唯一的 server_id 外，还需要特别注意以下几点：

• 避免自环复制：当多个主库之间相互同步数据时，如果配置不当，可能会出现数据循环复制的情况，即自环复制。为了避免这种情况，可以使用 log-slave-updates 参数，并在每个主库上设置合适的过滤规则，确保不会重复应用已经同步过的事务。

• 冲突解决：由于多个主库可能同时对相同的数据进行写入操作，这就可能导致数据冲突。在 MariaDB 中，可以通过一些机制来解决冲突，例如使用 auto_increment 字段的不同步策略或者应用更复杂的冲突检测和解决算法。

9.2 GTID 与半同步复制

半同步复制是一种在主从复制基础上提高数据安全性的机制。在传统的异步复制中，主库在提交事务后立即返回给客户端，并不等待从库确认接收到事务日志。而半同步复制要求主库在提交事务后，至少等待一个从库确认接收到事务日志才返回给客户端。

GTID 与半同步复制可以很好地结合使用。在 GTID 模式下，半同步复制可以确保事务按照 GTID 的顺序被从库接收和应用，进一步提高数据的一致性和可靠性。要启用半同步复制，需要在主库和从库上分别进行以下配置：

• 主库配置：在主库的配置文件中添加或修改以下参数：

  [mysqld]
  plugin-load=rpl_semi_sync_master=semisync_master.so
  rpl_semi_sync_master_enabled=ON
  rpl_semi_sync_master_timeout=10000
  

  • plugin-load 加载半同步复制主库插件。
  • rpl_semi_sync_master_enabled 启用半同步复制主库功能。
  • rpl_semi_sync_master_timeout 设置主库等待从库确认的超时时间（单位为毫秒）。

• 从库配置：在从库的配置文件中添加或修改以下参数：

  [mysqld]
  plugin-load=rpl_semi_sync_slave=semisync_slave.so
  rpl_semi_sync_slave_enabled=ON
  

  • plugin-load 加载半同步复制从库插件。
  • rpl_semi_sync_slave_enabled 启用半同步复制从库功能。

配置完成后，重启 MariaDB 服务使配置生效。然后在主库和从库上分别通过 INSTALL PLUGIN 命令安装相应的插件：

-- 主库安装插件
INSTALL PLUGIN rpl_semi_sync_master SONAME'semisync_master.so';
-- 从库安装插件
INSTALL PLUGIN rpl_semi_sync_slave SONAME'semisync_slave.so';

9.3 GTID 与并行复制

并行复制是提高 MariaDB 复制性能的另一种技术。在传统的复制方式下，从库的 SQL 线程是单线程的，只能按顺序应用主库发送过来的事务日志，这在高并发写入的场景下可能成为性能瓶颈。

GTID 为并行复制提供了更好的支持。MariaDB 基于 GTID 的并行复制可以根据 GTID 的信息，将不同的事务分配到多个线程中并行应用，从而提高复制的速度。要启用并行复制，需要在从库的配置文件中添加或修改以下参数：

[mysqld]
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=4

• slave_parallel_type 设置并行复制的类型，LOGICAL_CLOCK 表示基于逻辑时钟的并行复制，它利用 GTID 来确定事务之间的依赖关系，从而实现并行应用。
• slave_parallel_workers 设置并行复制的线程数，可根据服务器的 CPU 核心数和业务负载进行调整。

启用并行复制后，从库的 SQL 线程会将事务分配到多个工作线程中并行执行，大大提高了复制的效率，尤其在主库高并发写入的场景下效果更为显著。

通过了解这些拓展知识，可以进一步优化基于 GTID 的 MariaDB 复制架构，使其在不同的业务场景下都能发挥出最佳性能，满足企业日益增长的数据处理和高可用性需求。无论是多主复制、半同步复制还是并行复制，都与 GTID 紧密结合，为数据库系统的架构设计和优化提供了更多的选择和可能。