MariaDB主从复制配置的最佳实践

1. MariaDB 主从复制概述

MariaDB 主从复制是一种数据库同步机制，它允许将一个 MariaDB 数据库服务器（主服务器）的数据复制到一个或多个其他 MariaDB 数据库服务器（从服务器）。这种机制在许多场景下都非常有用，比如实现数据备份、分担读负载以及提高系统的可用性。

在主从复制过程中，主服务器记录所有影响数据的写操作到二进制日志（binary log）中。从服务器通过 I/O 线程连接到主服务器，读取主服务器的二进制日志，并将其记录到自己的中继日志（relay log）中。然后，从服务器的 SQL 线程读取中继日志，并在从服务器上重放这些日志记录，从而使从服务器的数据与主服务器保持一致。

2. 环境准备

在开始配置 MariaDB 主从复制之前，需要准备好以下环境：

操作系统：本文以 CentOS 7 为例进行演示。你可以根据实际情况选择其他支持 MariaDB 的操作系统。
MariaDB 版本：确保主从服务器上安装的 MariaDB 版本兼容性良好。本文以 MariaDB 10.3 版本为例。
网络配置：主从服务器之间需要能够通过网络相互通信。可以通过配置防火墙规则允许 MariaDB 服务所使用的端口（默认 3306）进行通信。例如，在 CentOS 7 上，可以使用以下命令开放 3306 端口：

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

3. 主服务器配置

3.1 修改 MariaDB 配置文件

在主服务器上，打开 MariaDB 的配置文件。在 CentOS 7 上，配置文件通常位于 /etc/my.cnf 或 /etc/mysql/my.cnf。在文件中添加或修改以下配置项：

[mysqld]
# 启用二进制日志
log-bin=mysql-bin
# 服务器唯一 ID，在主从复制环境中必须唯一
server-id=1
# 配置需要同步的数据库，多个数据库用逗号分隔
binlog-do-db=your_database_name
# 配置不需要同步的数据库
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema

其中，log-bin 开启二进制日志功能，server-id 是每个服务器在复制环境中的唯一标识，binlog-do-db 指定需要同步的数据库，binlog-ignore-db 用于排除不需要同步的系统数据库。

修改完成后，保存并关闭配置文件，然后重启 MariaDB 服务：

systemctl restart mariadb

3.2 创建用于主从复制的用户

登录到主服务器的 MariaDB 数据库：

mysql -u root -p

然后创建一个用于主从复制的用户，并授予其必要的权限。例如：

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

这里创建了一个名为 repl_user 的用户，允许其从任何主机连接（@'%'），并授予其 REPLICATION SLAVE 权限，这是从服务器连接主服务器进行复制所必需的权限。

3.3 获取主服务器状态

执行以下命令获取主服务器的二进制日志文件名和位置：

SHOW MASTER STATUS;

输出结果类似如下：

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |     154  | your_database_name | mysql,information_schema,performance_schema |                   |
+------------------+----------+--------------+------------------+-------------------+

记录下 File 和 Position 的值，后续配置从服务器时会用到。

4. 从服务器配置

4.1 修改 MariaDB 配置文件

在从服务器上，同样打开 MariaDB 的配置文件，并添加或修改以下配置项：

[mysqld]
# 服务器唯一 ID，在主从复制环境中必须唯一且不同于主服务器
server-id=2

这里的 server-id 设置为 2，确保与主服务器的 server-id 不同。修改完成后，保存并关闭配置文件，然后重启 MariaDB 服务：

systemctl restart mariadb

4.2 配置从服务器连接主服务器

登录到从服务器的 MariaDB 数据库：

mysql -u root -p

然后执行以下命令配置从服务器连接主服务器：

CHANGE MASTER TO
    MASTER_HOST='master_server_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='your_password',
    MASTER_LOG_FILE='mysql-bin.000003',
    MASTER_LOG_POS=154;

其中，MASTER_HOST 是主服务器的 IP 地址，MASTER_USER 和 MASTER_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，表示从服务器的 I/O 线程和 SQL 线程都在正常运行。同时，Seconds_Behind_Master 字段表示从服务器落后主服务器的时间，如果该值为 0 或较小的数值，说明复制延迟较小。

5. 常见问题及解决方法

5.1 主从复制延迟问题

原因分析：主从复制延迟可能由多种原因引起。例如，主服务器写操作过于频繁，从服务器硬件性能不足，网络延迟较高，或者从服务器上的其他进程占用过多资源等。
解决方法：可以通过优化主服务器的写操作，如批量插入数据而不是单个插入；提升从服务器的硬件配置，如增加内存、更换更快的磁盘等；检查网络连接并优化网络设置；查看从服务器上是否有其他高负载进程，并适当调整其资源占用。

5.2 从服务器复制进程停止问题

原因分析：从服务器复制进程停止可能是由于网络中断、主从服务器之间的配置不一致、主服务器的二进制日志损坏等原因导致。
解决方法：首先检查网络连接是否正常，可以通过 ping 命令测试主从服务器之间的连通性。如果网络正常，检查主从服务器的配置是否正确，特别是 CHANGE MASTER TO 命令中的参数是否与主服务器的配置一致。如果怀疑主服务器的二进制日志损坏，可以尝试在主服务器上重新生成二进制日志，并在从服务器上重新配置连接。

5.3 数据不一致问题

原因分析：数据不一致可能是由于在主从复制过程中，在从服务器上手动修改了数据，或者主从服务器之间的复制出现错误，导致部分数据没有正确同步。
解决方法：尽量避免在从服务器上手动修改数据。如果发现数据不一致，可以尝试停止从服务器的复制进程，使用主服务器的数据备份在从服务器上进行恢复，然后重新配置主从复制。具体步骤如下：

在主服务器上创建数据备份：

mysqldump -u root -p --all-databases > master_backup.sql

将备份文件传输到从服务器：

scp master_backup.sql slave_server_ip:/path/to/save/

在从服务器上停止复制进程并清空数据：

STOP SLAVE;
DROP DATABASE your_database_name;

在从服务器上恢复主服务器的备份数据：

mysql -u root -p < master_backup.sql

重新配置从服务器连接主服务器并启动复制进程：

CHANGE MASTER TO
    MASTER_HOST='master_server_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='your_password',
    MASTER_LOG_FILE='mysql-bin.000003',
    MASTER_LOG_POS=154;
START SLAVE;

6. 性能优化

6.1 优化主服务器性能

批量操作：尽量使用批量插入、更新等操作，减少单个 SQL 语句的执行次数。例如，在插入数据时，可以将多条数据合并到一个 INSERT 语句中：

INSERT INTO your_table (column1, column2) VALUES
('value1', 'value2'),
('value3', 'value4'),
('value5', 'value6');

优化查询：对主服务器上执行的查询进行优化，使用合适的索引，避免全表扫描。可以通过 EXPLAIN 关键字分析查询语句的执行计划，找出性能瓶颈。例如：

EXPLAIN SELECT * FROM your_table WHERE column1 = 'value';

合理分配资源：确保主服务器有足够的内存和 CPU 资源来处理写操作。可以根据服务器的硬件配置和业务需求，合理调整 MariaDB 的配置参数，如 innodb_buffer_pool_size 等。

6.2 优化从服务器性能

多线程复制：从 MariaDB 10.0 版本开始支持多线程复制，可以通过修改配置文件启用多线程复制功能。在从服务器的配置文件中添加或修改以下配置项：

[mysqld]
slave_parallel_workers=4
slave_parallel_type=LOGICAL_CLOCK

这里设置了 slave_parallel_workers 为 4，表示使用 4 个线程进行复制，slave_parallel_type 设置为 LOGICAL_CLOCK，表示基于逻辑时钟的并行复制模式。修改完成后，重启 MariaDB 服务使配置生效。

优化网络：确保从服务器与主服务器之间的网络连接稳定且带宽充足。可以通过调整网络设备的配置，如路由器、交换机等，优化网络性能。同时，避免在从服务器上进行大量的网络 I/O 操作，以免影响复制性能。
合理使用缓存：在从服务器上可以合理使用缓存技术，如 Memcached 或 Redis，来减轻数据库的读压力。将经常查询的数据缓存到内存中，当有查询请求时，先从缓存中获取数据，如果缓存中没有，则再从数据库中查询，并将查询结果缓存起来。

7. 高可用配置

7.1 使用 MHA（Master High Availability）实现高可用

MHA 简介：MHA 是一个用于 MariaDB 和 MySQL 的高可用解决方案，它可以在主服务器发生故障时自动将从服务器提升为主服务器，确保服务的连续性。
安装 MHA：在所有服务器（包括主服务器和从服务器）上安装 MHA 软件包。以 CentOS 7 为例，可以使用以下命令安装：

yum install mha4mysql-manager mha4mysql-node -y

配置 MHA：在主服务器上创建 MHA 的配置文件，例如 /etc/mha/app1.cnf，内容如下：

[server default]
manager_workdir=/var/log/mha/app1
manager_log=/var/log/mha/app1/manager.log
master_binlog_dir=/var/lib/mysql
user=mha_user
password=mha_password
ping_interval=2
repl_password=your_password
repl_user=repl_user

[server1]
hostname=master_server_ip
candidate_master=1
check_repl_delay=0

[server2]
hostname=slave_server1_ip
candidate_master=1

[server3]
hostname=slave_server2_ip

其中，manager_workdir 和 manager_log 分别指定 MHA 的工作目录和日志文件路径，master_binlog_dir 是主服务器二进制日志的存储目录，user 和 password 是 MHA 管理用户及其密码，ping_interval 表示 MHA 检测主服务器状态的时间间隔。每个 [serverX] 段定义了服务器的主机名，candidate_master 表示该服务器是否可以作为候选主服务器，check_repl_delay 设置为 0 表示不检查复制延迟。

在从服务器上，创建一个用于 MHA 的用户，并授予相应的权限：

CREATE USER 'mha_user'@'%' IDENTIFIED BY 'mha_password';
GRANT REPLICATION CLIENT, PROCESS ON *.* TO 'mha_user'@'%';
FLUSH PRIVILEGES;

启动 MHA：在主服务器上启动 MHA 管理进程：

masterha_manager --conf=/etc/mha/app1.cnf

可以通过以下命令查看 MHA 的状态：

masterha_check_status --conf=/etc/mha/app1.cnf

当主服务器发生故障时，MHA 会自动检测并将其中一个从服务器提升为主服务器，确保服务的可用性。

7.2 使用 Orchestrator 实现高可用

Orchestrator 简介：Orchestrator 是一个开源的 MySQL 和 MariaDB 集群管理工具，它提供了自动故障检测、故障转移以及拓扑管理等功能。
安装 Orchestrator：可以从 Orchestrator 的官方 GitHub 仓库下载安装包，并根据操作系统的不同进行安装。例如，在 Ubuntu 上可以使用以下命令安装：

wget https://github.com/github/orchestrator/releases/download/v3.2.10/orchestrator_3.2.10_amd64.deb
dpkg -i orchestrator_3.2.10_amd64.deb

配置 Orchestrator：编辑 Orchestrator 的配置文件，通常位于 /etc/orchestrator/orchestrator.conf.json，内容如下：

{
    "MySQLTopology": {
        "MaxReplicationLagSeconds": 300,
        "ReplicationLagCriticalAt": 600,
        "UseSSL": false,
        "Flavor": "mariadb",
        "ServerParams": [
            {
                "ServerDSN": "orchestrator_user:orchestrator_password@tcp(master_server_ip:3306)/",
                "IsClusterAlias": true
            },
            {
                "ServerDSN": "orchestrator_user:orchestrator_password@tcp(slave_server1_ip:3306)/"
            },
            {
                "ServerDSN": "orchestrator_user:orchestrator_password@tcp(slave_server2_ip:3306)/"
            }
        ]
    },
    "Server": {
        "HTTPListenAddress": "0.0.0.0:3000",
        "TLSCertFile": "",
        "TLSKeyFile": ""
    }
}

其中，MaxReplicationLagSeconds 定义了最大复制延迟时间，ReplicationLagCriticalAt 表示复制延迟达到此时间会被视为严重，Flavor 指定数据库类型为 MariaDB，ServerParams 中定义了主从服务器的连接信息。Server 段中指定了 Orchestrator 的 HTTP 监听地址。

在所有服务器上创建用于 Orchestrator 的用户，并授予相应的权限：

CREATE USER 'orchestrator_user'@'%' IDENTIFIED BY 'orchestrator_password';
GRANT REPLICATION CLIENT, PROCESS, SUPER ON *.* TO 'orchestrator_user'@'%';
FLUSH PRIVILEGES;

启动 Orchestrator：在安装 Orchestrator 的服务器上启动服务：

systemctl start orchestrator

可以通过浏览器访问 http://orchestrator_server_ip:3000 打开 Orchestrator 的 Web 界面，查看和管理 MariaDB 集群的状态。当主服务器发生故障时，Orchestrator 会自动进行故障转移，将合适的从服务器提升为主服务器。

8. 监控与维护

8.1 监控主从复制状态

使用 SHOW SLAVE STATUS 命令：通过在从服务器上执行 SHOW SLAVE STATUS \G 命令，可以实时查看从服务器的复制状态。除了前面提到的 Slave_IO_Running、Slave_SQL_Running 和 Seconds_Behind_Master 字段外，还可以关注 Last_IO_Error 和 Last_SQL_Error 字段，它们记录了 I/O 线程和 SQL 线程在复制过程中发生的错误信息。如果这两个字段不为空，说明复制过程中出现了问题，需要及时排查解决。
使用监控工具：可以使用一些第三方监控工具，如 Nagios、Zabbix 等，对 MariaDB 的主从复制状态进行监控。这些工具可以设置报警规则，当主从复制出现异常时及时通知管理员。以 Zabbix 为例，可以通过编写自定义脚本获取 SHOW SLAVE STATUS 的相关信息，并将其作为 Zabbix 的监控项进行监控。例如，编写一个名为 check_mariadb_slave_status.sh 的脚本：

#!/bin/bash
mysql -u root -p -e "SHOW SLAVE STATUS \G" | grep -E "Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master" | awk -F: '{print $2}' | tr '\n' ' '

设置脚本的执行权限：

chmod +x check_mariadb_slave_status.sh

在 Zabbix 中配置自定义监控项，设置键值为 custom.mariadb.slave.status，并指定脚本的路径作为脚本执行命令。这样就可以在 Zabbix 中实时监控 MariaDB 从服务器的复制状态。

8.2 定期备份与恢复

备份策略：为了防止数据丢失，需要制定合理的备份策略。可以采用全量备份和增量备份相结合的方式。全量备份可以定期（如每周一次）进行，使用 mysqldump 命令对整个数据库进行备份：

mysqldump -u root -p --all-databases > full_backup_$(date +%Y%m%d).sql

增量备份可以基于主服务器的二进制日志进行。在主服务器上，可以通过 SHOW MASTER STATUS 命令获取当前二进制日志的文件名和位置，然后定期将新生成的二进制日志文件进行备份。例如：

cp /var/lib/mysql/mysql-bin.000003 /backup/mysql-bin.000003_$(date +%Y%m%d)

恢复操作：当需要恢复数据时，如果是基于全量备份恢复，可以直接使用备份文件进行恢复：

mysql -u root -p < full_backup_20231001.sql

如果需要结合增量备份进行恢复，首先恢复全量备份，然后按照备份的顺序依次应用增量备份的二进制日志文件。在从服务器上，可以使用 mysqlbinlog 命令将二进制日志文件中的记录重放到数据库中：

mysqlbinlog /backup/mysql-bin.000003_20231002 | mysql -u root -p

8.3 日志管理

二进制日志管理：主服务器的二进制日志会不断增长，需要定期清理。可以通过 PURGE BINARY LOGS 命令删除不再需要的二进制日志文件。例如，删除所有早于 mysql-bin.000005 的二进制日志文件：

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

也可以设置 expire_logs_days 参数来自动删除过期的二进制日志文件。在主服务器的配置文件中添加或修改以下配置项：

[mysqld]
expire_logs_days=7

这表示二进制日志文件在 7 天后会自动被删除。修改完成后，重启 MariaDB 服务使配置生效。

中继日志管理：从服务器的中继日志也需要进行管理。当从服务器的复制进程正常运行时，中继日志会自动被清理。但如果复制过程中出现问题，中继日志可能会不断增长。可以通过 RESET SLAVE 命令来清理中继日志，但执行此命令会重置从服务器的复制配置，需要重新配置从服务器连接主服务器。在执行 RESET SLAVE 之前，请确保已经备份了必要的数据。

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO
    MASTER_HOST='master_server_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='your_password',
    MASTER_LOG_FILE='mysql-bin.000003',
    MASTER_LOG_POS=154;
START SLAVE;

通过以上详细的配置、优化、高可用设置以及监控维护措施，可以实现 MariaDB 主从复制的最佳实践，确保数据库系统的稳定运行和数据的一致性与可用性。在实际应用中，还需要根据业务需求和服务器环境进行灵活调整和优化。