MariaDB复制技术全面解析 - 摩柯技术社区

MariaDB 复制技术概述

MariaDB 的复制技术是一种数据同步机制，它允许将一个 MariaDB 数据库服务器（称为主服务器，Master）的数据更改复制到一个或多个其他 MariaDB 数据库服务器（称为从服务器，Slave）。这种技术在很多场景下都极为有用，比如负载均衡、数据备份、容灾恢复等。

在 MariaDB 复制过程中，主服务器将数据更改记录到二进制日志（Binary Log）中。从服务器通过 I/O 线程连接到主服务器，读取主服务器的二进制日志，并将其写入到自己的中继日志（Relay Log）中。然后，从服务器的 SQL 线程读取中继日志，执行其中记录的 SQL 语句，从而使从服务器的数据与主服务器保持一致。

复制拓扑结构

一主一从

这是最基本的复制拓扑结构，一个主服务器将数据复制到一个从服务器。这种结构适合简单的备份场景，例如在开发环境或测试环境中，将主服务器的数据备份到从服务器，以防主服务器数据丢失。

一主多从

在这种结构中，一个主服务器向多个从服务器复制数据。它常用于负载均衡场景，多个从服务器可以分担读请求，减轻主服务器的压力。例如，在一个高流量的网站中，主服务器负责处理写操作，而多个从服务器处理读操作，从而提高系统的整体性能。

主主复制

主主复制是指两个 MariaDB 服务器相互作为对方的主服务器和从服务器。这种结构提供了更高的可用性，任何一个服务器出现故障，另一个服务器可以继续提供服务。同时，两个服务器都可以进行读写操作，数据会在两个服务器之间双向同步。

链式复制

链式复制中，从服务器不仅接收主服务器的数据复制，还可以作为其他从服务器的主服务器，将数据继续向下复制。这种结构可以减轻主服务器的负载，特别是在大规模部署中，当有大量从服务器时，链式复制可以避免主服务器成为瓶颈。

配置 MariaDB 复制

主服务器配置

修改配置文件 打开 MariaDB 的配置文件，通常是 /etc/my.cnf 或 /etc/mysql/mariadb.conf.d/50-server.cnf。在 [mysqld] 部分添加或修改以下参数：

server-id = 1
log-bin = /var/log/mysql/mysql-bin.log
binlog-format = ROW

server-id 是每个服务器的唯一标识，不同服务器的 server-id 必须不同。log-bin 用于指定二进制日志的路径和文件名。binlog-format 设置为 ROW 格式，这种格式记录的是实际的数据行更改，相比其他格式更安全、更高效。

重启 MariaDB 服务 修改配置文件后，需要重启 MariaDB 服务使配置生效：

sudo systemctl restart mariadb

创建复制用户 登录到 MariaDB 数据库，创建一个专门用于复制的用户，并授予其必要的权限：

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

这里 repl_user 是复制用户的用户名，% 表示该用户可以从任何主机连接，password 是用户密码。

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

SHOW MASTER STATUS;

结果类似如下：

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 154      |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

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

从服务器配置

修改配置文件 同样打开 MariaDB 的配置文件，在 [mysqld] 部分添加或修改以下参数：

server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log

server-id 必须与主服务器不同，relay-log 用于指定中继日志的路径和文件名。

重启 MariaDB 服务 修改配置后重启服务：

sudo systemctl restart mariadb

配置主服务器信息 登录到从服务器的 MariaDB 数据库，执行以下命令配置主服务器信息：

CHANGE MASTER TO
    MASTER_HOST='master_host_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=154;

master_host_ip 是主服务器的 IP 地址，repl_user 和 password 是在主服务器上创建的复制用户及其密码，MASTER_LOG_FILE 和 MASTER_LOG_POS 是在主服务器上执行 SHOW MASTER STATUS 得到的值。

启动从服务器 执行以下命令启动从服务器：

START SLAVE;

检查从服务器状态 执行以下命令检查从服务器状态：

SHOW SLAVE STATUS \G;

重点关注 Slave_IO_Running 和 Slave_SQL_Running 字段，它们的值都应该为 Yes。同时，Seconds_Behind_Master 字段表示从服务器落后主服务器的时间，如果该值为 0 或接近 0，表示复制正常。

MariaDB 复制技术原理深入

二进制日志（Binary Log）

二进制日志是 MariaDB 复制的核心组件之一。主服务器将数据更改操作记录到二进制日志中，这些记录以一种紧凑、高效的格式存储，以便从服务器能够快速读取和应用。二进制日志的格式有三种：STATEMENT、ROW 和 MIXED。

STATEMENT 格式 在 STATEMENT 格式下，二进制日志记录的是 SQL 语句本身。例如，如果执行 UPDATE users SET age = age + 1 WHERE city = 'New York';，二进制日志中会记录这条 SQL 语句。这种格式的优点是日志文件相对较小，因为只记录 SQL 语句。但是，它在某些情况下可能会导致主从数据不一致，比如使用了函数（如 NOW()）或存储过程，因为在主从服务器上执行这些函数或存储过程可能会得到不同的结果。
ROW 格式 ROW 格式记录的是实际的数据行更改。继续以上面的 UPDATE 语句为例，ROW 格式会记录哪些行的 age 字段被修改以及修改前后的值。这种格式更加安全和可靠，因为它直接记录了数据的变化，不会受到函数或存储过程执行结果差异的影响。但是，由于要记录每一行的变化，日志文件相对较大。
MIXED 格式 MIXED 格式结合了 STATEMENT 和 ROW 格式的优点。默认情况下，MariaDB 使用 STATEMENT 格式记录日志，但对于一些可能导致主从数据不一致的操作（如使用函数），会自动切换到 ROW 格式记录。

中继日志（Relay Log）

从服务器通过 I/O 线程从主服务器读取二进制日志，并将其写入到中继日志中。中继日志的作用是在从服务器上临时存储主服务器的二进制日志，以便 SQL 线程可以逐步读取并应用其中的更改。中继日志的结构与二进制日志类似，但它只在从服务器上存在，并且在应用完其中的更改后可以被删除。

I/O 线程和 SQL 线程

I/O 线程 从服务器的 I/O 线程负责连接主服务器，读取主服务器的二进制日志，并将其写入到中继日志中。I/O 线程会定期检查主服务器的二进制日志是否有新的更改，如果有，则将新的日志内容追加到中继日志中。
SQL 线程 SQL 线程负责读取中继日志，并将其中记录的 SQL 语句在从服务器上执行，从而使从服务器的数据与主服务器保持一致。SQL 线程按照中继日志中记录的顺序依次执行 SQL 语句，确保数据的一致性。

复制故障排除

常见故障及解决方法

从服务器连接失败
- 原因：可能是网络问题、复制用户权限不足、主服务器配置错误等。
- 解决方法：首先检查网络连接，确保从服务器可以访问主服务器。然后检查复制用户的权限，在主服务器上重新授予权限并刷新权限。如果主服务器配置有误，仔细检查 server-id、log-bin 等参数是否正确配置。
从服务器同步延迟
- 原因：可能是主服务器负载过高，导致二进制日志生成过快；从服务器性能不足，无法及时处理中继日志；网络延迟等。
- 解决方法：优化主服务器性能，减少不必要的负载。提升从服务器的硬件配置，如增加内存、CPU 等。检查网络连接，确保网络稳定，减少网络延迟。
主从数据不一致
- 原因：可能是二进制日志格式设置不当、从服务器执行 SQL 语句出错、复制过程中出现中断等。
- 解决方法：如果是二进制日志格式问题，根据实际情况调整为合适的格式。检查从服务器的错误日志，找出执行 SQL 语句出错的原因并解决。如果复制过程中断，重新配置从服务器，确保其与主服务器重新同步。

高级复制技术

GTID（全局事务标识符）复制

GTID 是 MariaDB 从 10.0 版本开始引入的一种增强型复制技术。在传统的复制方式中，从服务器通过记录主服务器的二进制日志文件名和位置来进行同步，这种方式在主服务器发生故障切换或日志轮换时可能会变得复杂。而 GTID 为每个事务分配一个全局唯一的标识符，从服务器通过 GTID 来跟踪和应用事务，大大简化了复制的管理和维护。

GTID 工作原理 当主服务器执行一个事务时，会为该事务生成一个 GTID。这个 GTID 包含了主服务器的 server-id 和一个递增的事务编号。事务被记录到二进制日志中，同时 GTID 也被记录。从服务器在同步时，根据 GTID 来判断哪些事务需要应用，而不是依赖于二进制日志的文件名和位置。
配置 GTID 复制 在主服务器和从服务器的配置文件中，添加或修改以下参数：

gtid_mode = ON
enforce_gtid_consistency = ON

重启 MariaDB 服务后，主从服务器就会启用 GTID 复制。在配置从服务器时，不再需要指定 MASTER_LOG_FILE 和 MASTER_LOG_POS，而是使用 MASTER_AUTO_POSITION = 1：

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

半同步复制

半同步复制是一种介于异步复制和同步复制之间的复制方式。在异步复制中，主服务器在将数据更改写入二进制日志后，就立即返回给客户端，不等待从服务器确认接收。这种方式性能较高，但存在数据丢失的风险，因为如果主服务器在从服务器接收数据之前发生故障，从服务器可能会丢失部分数据。

同步复制则要求主服务器在所有从服务器确认接收数据更改后，才返回给客户端。这种方式数据安全性高，但性能较低，因为主服务器需要等待所有从服务器的确认，增加了响应时间。

半同步复制结合了两者的优点，主服务器在将数据更改写入二进制日志后，等待至少一个从服务器确认接收后，才返回给客户端。这样既保证了一定的数据安全性，又不会像同步复制那样严重影响性能。

配置半同步复制 在主服务器和从服务器上安装半同步复制插件：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

在主服务器配置文件中添加以下参数：

rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 10000

在从服务器配置文件中添加以下参数：

rpl_semi_sync_slave_enabled = 1

重启 MariaDB 服务后，半同步复制就配置完成了。

复制性能优化

优化主服务器

合理配置二进制日志 根据实际需求选择合适的二进制日志格式。如果对数据一致性要求极高，优先选择 ROW 格式；如果对日志文件大小比较敏感，且操作较为简单，可以考虑 STATEMENT 格式。同时，合理设置二进制日志的刷新频率，避免过于频繁地写入日志影响性能。
优化数据库操作 减少大事务的执行，将大事务拆分成多个小事务。大事务会导致二进制日志文件快速增长，并且在从服务器应用时可能会占用较长时间，导致同步延迟。优化 SQL 语句，确保其执行效率，减少主服务器的负载。

优化从服务器

提升硬件性能 如果从服务器性能不足，会导致同步延迟。可以根据实际情况增加内存、CPU 等硬件资源，提高从服务器处理中继日志的能力。
优化中继日志处理 合理设置中继日志的大小和清理策略。避免中继日志文件过大占用过多磁盘空间，同时也要确保在从服务器处理日志时不会因为日志文件过小而频繁切换。可以通过调整 relay_log_size 和 expire_logs_days 等参数来优化中继日志的管理。

网络优化

确保主从服务器之间的网络稳定，减少网络延迟和丢包。可以通过优化网络拓扑结构、增加网络带宽等方式来提升网络性能，保证主从服务器之间的数据传输顺畅。

总结 MariaDB 复制技术应用场景

数据备份 通过将主服务器的数据复制到从服务器，可以实现数据的实时备份。在主服务器出现故障时，可以快速切换到从服务器，保证数据的可用性。
负载均衡 利用一主多从的拓扑结构，将读请求分发到多个从服务器上，减轻主服务器的压力，提高系统的整体性能。特别是在高并发读的场景下，如电商网站的商品浏览页面，负载均衡可以显著提升用户体验。
容灾恢复 在不同地理位置部署主从服务器，可以实现容灾恢复。如果某个地区的主服务器因为自然灾害、人为错误等原因发生故障，其他地区的从服务器可以接管服务，确保业务的连续性。
数据分发 在分布式系统中，MariaDB 复制技术可以用于将数据分发到不同的节点。例如，在一个跨地区的企业应用中，总部的数据库可以作为主服务器，将数据复制到各个分支机构的从服务器，实现数据的实时同步和共享。

通过深入理解 MariaDB 复制技术的原理、配置方法、故障排除以及性能优化等方面，数据库管理员和开发人员可以更好地利用这一技术，构建高性能、高可用的数据存储和处理系统。无论是小型应用还是大型企业级系统，MariaDB 复制技术都能在数据管理和分发中发挥重要作用。