面试题：MariaDB GTID复制环境搭建与故障处理

Question

假设你要搭建一个基于MariaDB GTID的一主两从复制环境，简述搭建步骤及需要注意的配置参数。若在复制过程中从库出现复制延迟，可能的原因有哪些，如何排查和解决？

Answer 1

搭建基于MariaDB GTID一主两从复制环境步骤

1. 主库配置
   • 修改配置文件（通常是my.cnf）：

[mysqld]
server-id = 1
log-bin = /var/lib/mysql/mysql-bin.log
gtid_mode = ON
enforce_gtid_consistency = ON

- 重启MariaDB服务使配置生效。
- 创建用于从库复制的用户并授权：

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

- 获取主库状态信息：

SHOW MASTER STATUS;

- 记录`File`和`Position`的值，后续从库配置需要用到。

2. 从库配置（两个从库步骤类似） - 修改配置文件（my.cnf）：

[mysqld]
server-id = 2  # 另一个从库设为3
gtid_mode = ON
enforce_gtid_consistency = ON

- 重启MariaDB服务。
- 配置从库连接主库：

CHANGE MASTER TO
    MASTER_HOST ='master_host_ip',
    MASTER_USER ='replication_user',
    MASTER_PASSWORD = 'password',
    MASTER_LOG_FILE ='master_log_file_name',
    MASTER_LOG_POS = master_log_position;

- 启动从库复制：

START SLAVE;

- 检查从库复制状态：

SHOW SLAVE STATUS\G;

确保Slave_IO_Running和Slave_SQL_Running都为Yes，Seconds_Behind_Master为0。

注意的配置参数

1. server - id：每个节点必须有唯一的server - id，用于标识节点。
2. gtid_mode：必须开启，确保基于GTID的复制。
3. enforce_gtid_consistency：开启以强制GTID一致性，确保事务按照GTID顺序执行。

从库复制延迟可能原因、排查及解决方法

1. 可能原因
   • 网络问题：主从库之间网络延迟高或不稳定。
   • 主库负载高：主库忙于处理大量事务，导致从库接收日志延迟。
   • 从库性能低：从库硬件资源不足，如CPU、内存、磁盘I/O性能差。
   • 大事务：主库执行大事务，从库应用日志花费时间长。
   • 复制线程问题：从库的I/O线程或SQL线程出现故障。
2. 排查方法
   • 网络排查：使用ping、traceroute等工具检查网络延迟和丢包情况。
   • 主库负载检查：通过SHOW STATUS查看主库的Threads_running、Innodb_row_lock_waits等指标判断负载。
   • 从库性能检查：监控从库服务器的CPU、内存、磁盘I/O使用率。
   • 大事务检查：在主库使用SHOW ENGINE INNODB STATUS查看当前事务情况。
   • 复制线程检查：通过SHOW SLAVE STATUS\G查看Slave_IO_Running和Slave_SQL_Running状态及错误信息。
3. 解决方法
   • 网络问题：优化网络配置，增加带宽或更换网络设备。
   • 主库负载高：优化主库查询，增加主库硬件资源，或者采用分库分表等方式减轻负载。
   • 从库性能低：升级从库硬件，优化从库配置，如调整InnoDB缓冲池大小。
   • 大事务：尽量避免执行大事务，将大事务拆分成小事务。
   • 复制线程问题：根据错误信息解决，如重新配置从库连接主库等。