MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

MariaDB主库已有数据时的复制配置策略

2021-09-107.7k 阅读

MariaDB 主库已有数据时的复制配置策略

在数据库管理中，数据复制是一项关键技术，它能够提升数据的可用性、实现负载均衡以及进行灾难恢复。MariaDB 作为一款流行的开源数据库，在处理主库已有数据时的复制配置，需要遵循特定的策略和步骤，以确保数据的完整性和复制的顺利进行。

1. MariaDB 复制原理概述

MariaDB 的复制基于主从模型，主库（Master）记录所有的数据更改操作到二进制日志（Binary Log）中。从库（Slave）通过 I/O 线程连接到主库，读取主库的二进制日志，并将其记录到自己的中继日志（Relay Log）中。然后，从库的 SQL 线程读取中继日志，并在从库上重放这些日志，从而使从库的数据与主库保持一致。

2. 准备工作

在开始配置复制之前，需要确保以下几点：

  • 主从库版本兼容：主库和从库的 MariaDB 版本应该尽量保持一致，避免因版本差异导致的兼容性问题。
  • 网络连通性：主库和从库之间必须能够相互通信，确保没有防火墙或网络策略阻止它们之间的连接。
  • 数据库用户权限：在主库上创建一个具有复制权限的用户，该用户将用于从库连接主库。

2.1 在主库上创建复制用户

登录到主库的 MariaDB 控制台，执行以下 SQL 语句创建一个用于复制的用户，并赋予其所需的权限：

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

上述代码中，repl_user 是创建的复制用户，% 表示该用户可以从任何主机连接，password 是用户的密码。GRANT REPLICATION SLAVE 语句赋予该用户复制相关的权限。

2.2 确定主库状态

在主库上执行以下命令，获取主库的二进制日志文件名和位置：

SHOW MASTER STATUS;

执行结果类似如下：

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mariadb-bin.000003 |      335 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.001 sec)

这里的 File（例如 mariadb-bin.000003）和 Position（例如 335）的值在后续配置从库时会用到。

3. 备份主库数据

由于主库已经有数据，为了确保从库能准确复制主库的状态，需要对主库进行备份，并将备份数据恢复到从库。

3.1 使用 mysqldump 进行备份

在主库所在服务器上，执行以下命令进行全量备份，包括数据库结构和数据：

mysqldump -u root -p --all-databases --master-data=2 > master_backup.sql

--master-data=2 选项会在备份文件中记录主库的二进制日志文件名和位置，格式如下：

-- CHANGE MASTER TO MASTER_LOG_FILE='mariadb-bin.000003', MASTER_LOG_POS=335;

执行上述命令后，系统会提示输入数据库 root 用户的密码。备份完成后，会生成一个 master_backup.sql 文件，该文件包含了主库的所有数据和结构，以及用于配置从库的主库日志位置信息。

3.2 传输备份文件到从库

将 master_backup.sql 文件通过 scp 等工具传输到从库服务器：

scp master_backup.sql slave_server:/path/to/destination

这里的 slave_server 是从库服务器的地址，/path/to/destination 是从库服务器上的目标路径。

4. 配置从库

在从库上完成数据恢复后，就可以进行复制配置了。

4.1 恢复主库备份数据

登录到从库的 MariaDB 控制台，创建一个数据库用户用于后续操作（如果还没有合适的用户），例如：

CREATE USER 'restore_user'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'restore_user'@'localhost';
FLUSH PRIVILEGES;

然后，使用以下命令将主库的备份数据恢复到从库：

mysql -u restore_user -p < master_backup.sql

执行该命令时，系统会提示输入 restore_user 用户的密码。恢复完成后，从库的数据结构和数据将与主库备份时一致。

4.2 配置从库复制参数

登录到从库的 MariaDB 控制台，根据备份文件中的 CHANGE MASTER TO 语句内容，配置从库连接主库的参数：

CHANGE MASTER TO
    MASTER_HOST='master_server',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mariadb-bin.000003',
    MASTER_LOG_POS=335;

这里的 master_server 是主库服务器的地址，repl_user 和 password 是在主库上创建的复制用户及其密码，MASTER_LOG_FILE 和 MASTER_LOG_POS 是之前在主库上通过 SHOW MASTER STATUS 获取的值。

4.3 启动从库复制

完成上述配置后，执行以下命令启动从库的复制：

START SLAVE;

可以通过以下命令查看从库的复制状态：

SHOW SLAVE STATUS \G

执行结果中，重点关注 Slave_IO_Running 和 Slave_SQL_Running 字段，如果两者都为 Yes，并且 Seconds_Behind_Master 字段的值为 0 或者较小的正数，说明从库复制正常运行。例如：

...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
...

如果 Slave_IO_Running 或 Slave_SQL_Running 为 No，需要根据错误信息排查问题。常见的问题包括网络连接问题、用户权限问题、日志位置配置错误等。

5. 基于 GTID 的复制配置

从 MariaDB 10.0 版本开始，支持基于全局事务标识符（GTID）的复制。GTID 是一种更简单、可靠的复制方式，它自动跟踪每个事务，避免了传统基于日志文件和位置的复制中可能出现的复杂配置问题。

5.1 启用 GTID

在主库和从库的 my.cnf 配置文件中，添加或修改以下配置项以启用 GTID：

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON

修改完成后，重启 MariaDB 服务使配置生效。

5.2 配置主库

在主库上创建复制用户（如果尚未创建）：

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

5.3 备份主库数据（GTID 模式）

使用 mysqldump 进行备份时，确保加上 --set-gtid-purged=ON 选项：

mysqldump -u root -p --all-databases --set-gtid-purged=ON > master_backup_gtid.sql

该选项会在备份文件中记录已应用的 GTID 集合，便于从库恢复和配置复制。

5.4 传输备份文件并恢复到从库

与传统方式类似，将备份文件传输到从库，并恢复数据：

scp master_backup_gtid.sql slave_server:/path/to/destination
mysql -u restore_user -p < master_backup_gtid.sql

5.5 配置从库复制（GTID 模式）

在从库上，配置连接主库的参数，使用 GTID 模式：

CHANGE MASTER TO
    MASTER_HOST='master_server',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_AUTO_POSITION=1;

这里的 MASTER_AUTO_POSITION=1 表示使用 GTID 自动定位主库位置，无需手动指定日志文件和位置。

5.6 启动从库复制（GTID 模式）

执行以下命令启动从库复制：

START SLAVE;

同样可以通过 SHOW SLAVE STATUS \G 查看从库状态，在 GTID 模式下，Slave_IO_Running 和 Slave_SQL_Running 应为 Yes，并且 Retrieved_Gtid_Set 和 Executed_Gtid_Set 应该一致。

6. 常见问题及解决方法

在 MariaDB 主库已有数据的复制配置过程中，可能会遇到各种问题，以下是一些常见问题及解决方法：

6.1 从库复制延迟

  • 原因：从库的硬件性能不足、网络延迟、主库负载过高、大事务等都可能导致从库复制延迟。
  • 解决方法：
    • 优化硬件：确保从库有足够的 CPU、内存和磁盘 I/O 资源。
    • 优化网络：检查网络连接，减少网络延迟和丢包。
    • 优化主库负载：对主库的查询和写入操作进行优化，避免长时间运行的大事务。
    • 并行复制：在 MariaDB 10.3 及以上版本，可以启用并行复制，通过配置 slave_parallel_workers 参数，让从库使用多个线程并行重放中继日志，提高复制速度。例如，在 my.cnf 文件中添加：
[mysqld]
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=4

这里将并行工作线程数设置为 4，可以根据实际情况调整。

6.2 从库 I/O 线程或 SQL 线程停止

  • 原因：常见原因包括主库网络不可达、复制用户权限不足、主从库数据不一致等。
  • 解决方法：
    • 检查网络：确保主库和从库之间网络连通，可以通过 ping 命令和 telnet 命令检查端口是否开放。
    • 检查权限：确认从库连接主库的复制用户权限是否正确，在主库上重新授予权限并在从库上重新配置。
    • 数据一致性检查：如果主从库数据不一致，可能需要重新进行备份恢复操作。可以使用 pt-table-checksum 等工具检查主从库数据一致性。例如，安装 percona-toolkit 后，在主库上执行：
pt-table-checksum --user=root --password=password --host=master_server

该工具会对比主从库的数据，并输出不一致的表和行信息，根据结果进行相应处理。

6.3 GTID 复制问题

  • 原因：GTID 配置错误、主从库 GTID 不一致等。
  • 解决方法：
    • 检查配置：确保主从库都正确启用了 GTID 模式，并且 gtid_mode 和 enforce_gtid_consistency 配置正确。
    • 重置 GTID：如果主从库 GTID 不一致，可以在从库上执行以下命令重置 GTID 并重新配置复制：
STOP SLAVE;
RESET MASTER;
RESET SLAVE ALL;
CHANGE MASTER TO
    MASTER_HOST='master_server',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_AUTO_POSITION=1;
START SLAVE;

注意，RESET MASTER 会清除主库的二进制日志，谨慎使用。

7. 监控与维护

为了确保 MariaDB 主从复制的稳定运行，需要定期进行监控和维护。

7.1 监控复制状态

可以通过 SHOW SLAVE STATUS \G 命令定期检查从库的复制状态，重点关注 Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master 等字段。可以编写脚本定时执行该命令，并通过邮件或其他监控工具发送状态报告。例如，使用 shell 脚本：

#!/bin/bash

mysql -u root -p -e "SHOW SLAVE STATUS \G" | grep -e 'Slave_IO_Running' -e 'Slave_SQL_Running' -e 'Seconds_Behind_Master' > slave_status.txt

# 发送邮件报告
echo "从库复制状态报告" | mail -s "MariaDB 从库状态" -A slave_status.txt your_email@example.com

上述脚本将从库状态信息保存到 slave_status.txt 文件，并通过邮件发送给指定邮箱。

7.2 备份与恢复测试

定期进行备份和恢复测试，确保在主库出现故障时能够快速恢复从库。可以使用测试环境模拟主库故障，验证从库能否正常接管业务，并检查数据的完整性。

7.3 日志管理

主库的二进制日志和从库的中继日志会不断增长，需要定期清理。在主库上，可以使用 PURGE BINARY LOGS 命令清理不再需要的二进制日志。例如，清理早于指定日志文件的所有二进制日志：

PURGE BINARY LOGS TO'mariadb-bin.000005';

在从库上，中继日志会在复制完成后自动清理，但如果出现异常，可以手动清理。先停止从库复制：

STOP SLAVE;

然后删除中继日志文件：

rm -f /var/lib/mysql/relay-bin*

最后重新启动从库复制：

START SLAVE;

通过以上详细的策略、步骤和常见问题解决方法，能够在 MariaDB 主库已有数据的情况下，成功配置可靠的主从复制，并进行有效的监控和维护，确保数据库系统的高可用性和数据一致性。无论是传统的基于日志文件和位置的复制，还是基于 GTID 的复制，都需要根据实际需求和环境进行合理选择和优化。在实际操作中，务必谨慎对待每一个步骤，特别是涉及数据备份、恢复和权限配置等关键环节，以保障数据的安全和稳定。