外观
MariaDB 复制环境部署与配置
复制概述
MariaDB 复制是实现高可用性、负载均衡和数据备份的基础机制。它通过将主库（Master）的二进制日志（Binary Log）传输到从库（Slave），并在从库上重放，实现数据的同步。
复制的主要类型包括：
- 异步复制（Asynchronous Replication）
- 半同步复制（Semi-Synchronous Replication）
- GTID复制（Global Transaction ID Replication）
- 多源复制（Multi-Source Replication）
异步复制部署与配置
异步复制是 MariaDB 默认的复制模式，主库在写入二进制日志后不需要等待从库确认，继续处理下一个事务。
部署准备
环境准备
- 主库：MariaDB 10.5+，IP：192.168.1.100
- 从库：MariaDB 10.5+，IP：192.168.1.101
- 确保主从库版本兼容（建议使用相同主版本）
- 网络连通性良好
配置主库
ini# 启用二进制日志 log_bin = /var/log/mysql/mariadb-bin binlog_format = ROW server_id = 100 # 设置二进制日志过期时间（7天） expire_logs_days = 7 # 允许从库连接 bind-address = 0.0.0.0配置从库
ini# 启用中继日志 relay_log = /var/log/mysql/relay-bin server_id = 101 read_only = ON # 允许从库连接 bind-address = 0.0.0.0重启主从库
bash# 主库 systemctl restart mariadb # 从库 systemctl restart mariadb
部署步骤
在主库上创建复制用户
sqlCREATE USER 'repl'@'192.168.1.101' IDENTIFIED BY 'repl_password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.101'; FLUSH PRIVILEGES;备份主库数据
bash# 使用 mariabackup 备份主库 mariabackup --backup --target-dir=/backup/initial --user=root --password=root_password # 准备备份文件 mariabackup --prepare --target-dir=/backup/initial # 将备份文件复制到从库 rsync -avP /backup/initial/ 192.168.1.101:/backup/initial/恢复从库数据
bash# 停止从库服务 systemctl stop mariadb # 清空数据目录 rm -rf /var/lib/mysql/* # 恢复备份 mariabackup --copy-back --target-dir=/backup/initial # 设置权限 chown -R mysql:mysql /var/lib/mysql # 启动从库 systemctl start mariadb配置从库复制连接
sql-- 查看备份文件中的二进制日志位置 cat /backup/initial/xtrabackup_binlog_info -- 在从库上配置复制 CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=107; -- 启动复制 START SLAVE; -- 查看复制状态 SHOW SLAVE STATUS\G
配置验证
在从库上执行 SHOW SLAVE STATUS\G，如果看到以下状态，则复制配置成功：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0GTID复制部署与配置
GTID（Global Transaction ID）复制使用全局唯一的事务ID来标识和跟踪每个事务，简化了复制的管理和故障转移。
配置步骤
配置主库
ini# 启用 GTID gtid_domain_id = 1 server_id = 100 log_bin = /var/log/mysql/mariadb-bin binlog_format = ROW # 启用 GTID 复制 gtid_strict_mode = ON enforce_gtid_consistency = ON配置从库
ini# 启用 GTID gtid_domain_id = 1 server_id = 101 relay_log = /var/log/mysql/relay-bin read_only = ON # 启用 GTID 复制 gtid_strict_mode = ON enforce_gtid_consistency = ON重启主从库
配置复制连接
sql-- 在从库上配置 GTID 复制 CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_USE_GTID=slave_pos; -- 启动复制 START SLAVE; -- 查看复制状态 SHOW SLAVE STATUS\G
GTID复制优势
- 简化复制配置和管理
- 便于故障转移和主从切换
- 支持多源复制和级联复制
- 提高复制的可靠性和一致性
半同步复制部署与配置
半同步复制是异步复制的增强版，主库在提交事务前需要至少一个从库确认接收了二进制日志。
配置步骤
安装半同步复制插件
sql-- 在主库上安装 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; -- 在从库上安装 INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';启用半同步复制
sql-- 在主库上启用 SET GLOBAL rpl_semi_sync_master_enabled = 1; SET GLOBAL rpl_semi_sync_master_timeout = 10000; -- 10秒超时 -- 在从库上启用 SET GLOBAL rpl_semi_sync_slave_enabled = 1;重启从库 IO 线程
sqlSTOP SLAVE IO_THREAD; START SLAVE IO_THREAD;验证半同步复制
sql-- 在主库上查看 SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_master_status'; -- 预期结果：Value: ON -- 在从库上查看 SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_slave_status'; -- 预期结果：Value: ON
半同步复制参数优化
| 参数名称 | 默认值 | 说明 | 建议值 |
|---|---|---|---|
| rpl_semi_sync_master_timeout | 10000 | 超时时间（毫秒） | 5000-30000 |
| rpl_semi_sync_master_wait_for_slave_count | 1 | 需要确认的从库数量 | 1-从库总数 |
| rpl_semi_sync_master_wait_no_slave | ON | 当没有从库可用时是否降级为异步复制 | ON |
| rpl_semi_sync_master_trace_level | 32 | 调试级别 | 32（生产环境） |
多源复制部署与配置
多源复制允许一个从库从多个主库复制数据，适用于数据整合和集中备份场景。
配置步骤
配置从库
iniserver_id = 101 relay_log = /var/log/mysql/relay-bin read_only = ON # 启用多源复制 slave_parallel_workers = 4 slave_parallel_type = LOGICAL_CLOCK配置复制连接
sql-- 配置第一个主库 CHANGE MASTER 'master1' TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=107; -- 配置第二个主库 CHANGE MASTER 'master2' TO MASTER_HOST='192.168.1.102', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=107; -- 启动所有主库的复制 START ALL SLAVES; -- 查看复制状态 SHOW ALL SLAVES STATUS\G
多源复制注意事项
- 确保不同主库的表结构不冲突
- 建议使用不同的数据库名区分不同主库的数据
- 监控每个主库的复制延迟
- 合理设置并行复制线程数
复制监控与维护
复制状态监控
查看复制状态
sql-- 单源复制 SHOW SLAVE STATUS\G -- 多源复制 SHOW ALL SLAVES STATUS\G监控复制延迟
sql-- 查看复制延迟 SELECT Seconds_Behind_Master FROM information_schema.processlist WHERE command = 'Slave SQL'; -- 使用性能 schema 监控 SELECT * FROM performance_schema.replication_applier_status_by_worker;监控二进制日志
sql-- 查看主库二进制日志状态 SHOW MASTER STATUS; SHOW BINARY LOGS; -- 查看从库中继日志状态 SHOW RELAYLOG EVENTS IN 'relay-bin.000001';
复制维护
修复复制错误
sql-- 跳过单个错误 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE SQL_THREAD; -- 跳过特定错误 -- 在配置文件中添加 slave_skip_errors = 1062,1032重置复制
sql-- 停止复制 STOP SLAVE; -- 重置复制配置 RESET SLAVE ALL; -- 重新配置复制 CHANGE MASTER TO ...; START SLAVE;清理二进制日志
sql-- 手动清理 PURGE BINARY LOGS TO 'mariadb-bin.000010'; PURGE BINARY LOGS BEFORE '2023-01-01 00:00:00'; -- 自动清理（通过配置文件） expire_logs_days = 7
复制优化
二进制日志优化
ini
# 使用 ROW 格式，提高复制可靠性
binlog_format = ROW
# 增大二进制日志文件大小
max_binlog_size = 1G
# 启用二进制日志校验
binlog_checksum = CRC32
# 优化二进制日志写入
sync_binlog = 1从库优化
ini
# 启用并行复制
slave_parallel_workers = 8
slave_parallel_type = LOGICAL_CLOCK
# 优化中继日志写入
relay_log_recovery = ON
relay_log_info_repository = TABLE
relay_log_purge = ON
# 优化从库读取
skip_slave_start = ON
read_only = ON网络优化
- 使用专用网络进行复制流量传输
- 配置合适的
slave_net_timeout参数 - 考虑使用压缩复制（MariaDB 10.1+ 支持）
复制常见问题及解决方案
问题 1：Slave_IO_Running: No
可能原因：
- 网络连接问题
- 复制用户权限不足
- 二进制日志文件不存在或已被清理
解决方案：
- 检查网络连通性：
ping 192.168.1.100 - 验证复制用户权限：
SHOW GRANTS FOR 'repl'@'192.168.1.101' - 检查主库二进制日志：
SHOW BINARY LOGS
问题 2：Slave_SQL_Running: No
可能原因：
- 从库执行事务时发生错误
- 主从库表结构不一致
- 数据冲突（如主键重复）
解决方案：
- 查看错误日志：
tail -f /var/log/mysql/error.log - 跳过错误：
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 - 修复数据冲突：手动同步不一致的数据
问题 3：Seconds_Behind_Master 持续增长
可能原因：
- 主库写入压力过大
- 从库硬件性能不足
- 网络延迟过高
- 并行复制配置不合理
解决方案：
- 优化主库查询性能
- 升级从库硬件配置
- 优化网络连接
- 调整并行复制线程数
问题 4：二进制日志文件过大
可能原因：
max_binlog_size设置过大expire_logs_days设置过小- 长时间运行的事务
解决方案：
- 调整
max_binlog_size为合理值（如 1G） - 设置合适的
expire_logs_days（如 7 天） - 优化长时间运行的事务
常见问题 (FAQ)
Q1：主从复制和 GTID 复制有什么区别？
A：主从复制使用二进制日志文件名和位置来跟踪复制进度，而 GTID 复制使用全局唯一的事务 ID。GTID 复制简化了复制管理和故障转移，提高了复制的可靠性。
Q2：半同步复制会影响主库性能吗？
A：半同步复制会导致主库提交事务的延迟增加，因为主库需要等待从库确认接收二进制日志。影响程度取决于网络延迟和从库性能。建议根据业务需求选择合适的超时时间。
Q3：如何实现复制的自动故障转移？
A：可以使用工具如 MariaDB MaxScale、ProxySQL、HAProxy 结合 Keepalived 实现自动故障转移。这些工具可以监控主库状态，并在主库故障时自动将从库提升为主库。
Q4：多源复制支持多少个主库？
A：MariaDB 理论上支持无限多个主库，但实际应用中建议根据从库的性能和网络带宽合理设置主库数量，一般不超过 10 个。
Q5：如何监控复制状态？
A：可以使用命令行工具如 SHOW SLAVE STATUS\G，或使用监控工具如 Prometheus + Grafana、Nagios、Zabbix 等进行可视化监控。建议配置告警机制，及时发现和处理复制问题。
Q6：如何处理复制延迟问题？
A：可以通过优化主库查询性能、升级从库硬件配置、调整并行复制线程数、使用专用网络等方式解决复制延迟问题。同时，建议监控复制延迟，及时发现并处理问题。
Q7：复制过程中主库崩溃怎么办？
A：如果主库崩溃，可以将一个从库提升为主库，然后重新配置其他从库指向新主库。使用 GTID 复制可以简化这个过程，因为不需要手动查找二进制日志位置。
Q8：如何验证复制数据的一致性？
A：可以使用工具如 pt-table-checksum 和 pt-table-sync 来验证和修复主从库数据一致性问题。这些工具可以检测主从库之间的数据差异，并生成修复脚本。