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

MariaDB中CHANGE MASTER TO命令的工作原理

2022-08-304.1k 阅读

MariaDB 复制架构基础

在深入探讨 CHANGE MASTER TO 命令的工作原理之前，我们先来了解一下 MariaDB 的复制架构。MariaDB 的复制是基于主从模式，主服务器（Master）记录所有的数据修改操作到二进制日志（Binary Log）中，从服务器（Slave）通过读取主服务器的二进制日志并在本地重放这些操作来保持数据的一致性。

在这个架构中，从服务器需要知道从主服务器的哪个位置开始读取二进制日志，这就涉及到了一些关键的信息，比如主服务器的地址、端口、用户名、密码，以及二进制日志的文件名和位置偏移量等。CHANGE MASTER TO 命令就是用来配置从服务器这些关键连接和复制相关参数的。

二进制日志与中继日志

  1. 二进制日志（Binary Log）
    • 主服务器上的二进制日志记录了所有影响数据库数据的修改操作，例如 INSERT、UPDATE、DELETE 语句，以及数据库结构修改语句如 CREATE TABLE、ALTER TABLE 等。二进制日志以文件形式存在，文件名通常类似于 mysql-bin.000001，mysql-bin.000002 等，每个文件达到一定大小（可通过配置参数设置）后会进行滚动。
    • 二进制日志中的每一条记录称为一个事件（Event），事件包含了操作的详细信息，比如执行的 SQL 语句、执行时间等。从服务器就是通过读取这些事件并在本地重放来同步数据。
  2. 中继日志（Relay Log）
    • 从服务器在复制过程中，会将从主服务器读取到的二进制日志事件暂存到中继日志中。中继日志的文件名格式类似于 relay-bin.000001，relay-bin.000002 等。
    • 从服务器的 SQL 线程负责从中继日志中读取事件并在本地数据库中重放，从而保持与主服务器的数据一致性。

CHANGE MASTER TO 命令语法

CHANGE MASTER TO 命令的基本语法如下：

CHANGE MASTER TO
    MASTER_HOST = 'master_host_name',
    MASTER_USER = 'replication_user',
    MASTER_PASSWORD = 'replication_password',
    MASTER_LOG_FILE = 'master_log_file_name',
    MASTER_LOG_POS = master_log_position,
    [MASTER_PORT = master_port],
    [MASTER_CONNECT_RETRY = retry_count],
    [MASTER_DELAY = delay_seconds];
  1. MASTER_HOST：主服务器的主机名或 IP 地址。
  2. MASTER_USER：用于复制的用户名，该用户需要具有 REPLICATION SLAVE 权限。
  3. MASTER_PASSWORD：上述复制用户的密码。
  4. MASTER_LOG_FILE：主服务器上二进制日志的文件名，从服务器将从该文件开始读取日志。
  5. MASTER_LOG_POS：主服务器上二进制日志中从服务器开始读取的位置偏移量。
  6. MASTER_PORT：主服务器的端口号，默认为 3306，如果主服务器使用了其他端口，需要明确指定。
  7. MASTER_CONNECT_RETRY：从服务器在连接主服务器失败后，重试连接的时间间隔（秒），默认为 60 秒。
  8. MASTER_DELAY：从服务器在应用中继日志事件时延迟的秒数，这在一些场景下，比如需要模拟一定时间的延迟复制时很有用。

CHANGE MASTER TO 命令工作原理详细解析

  1. 连接信息配置
    • 当执行 CHANGE MASTER TO 命令时，首先会配置从服务器连接主服务器所需的信息，即 MASTER_HOST、MASTER_USER、MASTER_PASSWORD 和 MASTER_PORT。从服务器使用这些信息来建立与主服务器的连接。如果主服务器启用了 SSL 连接，还可以通过额外的参数配置 SSL 相关信息，如 MASTER_SSL = {0|1}，MASTER_SSL_CA = 'ca_file_path' 等。
    • 例如，以下命令配置了从服务器连接到主服务器的基本信息：
CHANGE MASTER TO
    MASTER_HOST = '192.168.1.100',
    MASTER_USER = 'repl_user',
    MASTER_PASSWORD = 'repl_password',
    MASTER_PORT = 3306;
  1. 日志位置定位
    • MASTER_LOG_FILE 和 MASTER_LOG_POS 参数指定了从服务器在主服务器二进制日志中的起始读取位置。这两个参数至关重要，因为它们决定了从服务器从何处开始同步数据。
    • 假设主服务器当前的二进制日志文件为 mysql-bin.000005，偏移量为 154。如果从服务器之前已经同步到了这个位置，之后由于某些原因（如主从重启、重新配置等）需要重新设置复制，就可以使用 CHANGE MASTER TO 命令指定从这个位置继续同步：
CHANGE MASTER TO
    MASTER_LOG_FILE = 'mysql-bin.000005',
    MASTER_LOG_POS = 154;
  • 获取主服务器当前二进制日志文件名和位置偏移量可以在主服务器上执行 SHOW MASTER STATUS 命令，如下所示：
SHOW MASTER STATUS;
  • 输出结果类似：
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000005 | 154      |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
  • 这里的 File 就是二进制日志文件名，Position 就是位置偏移量。
  1. 连接重试与延迟设置
    • MASTER_CONNECT_RETRY 参数设置了从服务器在连接主服务器失败后重试连接的时间间隔。例如，如果设置为 30，表示从服务器每 30 秒尝试重新连接主服务器一次。这在主服务器临时不可用等情况下很有用，确保从服务器能够及时恢复连接并继续同步数据。
    • MASTER_DELAY 参数则用于设置从服务器应用中继日志事件的延迟时间。比如设置为 600，表示从服务器会延迟 600 秒（10 分钟）应用从主服务器接收到的日志事件。这种延迟复制在一些场景下很有价值，例如在进行数据备份时，可以利用延迟复制，先在延迟的从服务器上进行备份操作，而不会影响主服务器和其他实时同步的从服务器。

CHANGE MASTER TO 命令与复制线程的交互

  1. I/O 线程
    • 配置完 CHANGE MASTER TO 相关参数后，从服务器的 I/O 线程会根据这些配置尝试连接主服务器。一旦连接成功，I/O 线程会在主服务器上注册为一个复制客户端，并开始请求主服务器发送二进制日志事件。
    • I/O 线程将接收到的二进制日志事件写入到本地的中继日志中。在这个过程中，I/O 线程会持续监控主服务器的二进制日志变化，确保及时获取新的事件。如果主服务器的二进制日志发生滚动（即达到文件大小限制创建新的日志文件），I/O 线程会自动切换到新的日志文件继续读取。
  2. SQL 线程
    • SQL 线程负责从本地的中继日志中读取事件并在从服务器的数据库中重放。在执行 CHANGE MASTER TO 命令后，SQL 线程会根据配置的起始位置（MASTER_LOG_FILE 和 MASTER_LOG_POS），从相应的中继日志位置开始重放事件。
    • 如果 MASTER_DELAY 参数被设置，SQL 线程会在重放事件前等待相应的延迟时间。例如，设置 MASTER_DELAY = 300，SQL 线程会在从中继日志读取到事件后，等待 300 秒才将该事件应用到从服务器的数据库中。

实际案例分析

假设我们有一个简单的 MariaDB 主从复制环境，主服务器 IP 为 192.168.1.100，从服务器 IP 为 192.168.1.101。

  1. 主服务器配置
    • 首先在主服务器上创建用于复制的用户，并授予 REPLICATION SLAVE 权限：
CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;
  • 然后查看主服务器的二进制日志状态：
SHOW MASTER STATUS;
  • 假设输出为：
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 120      |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
  1. 从服务器配置
    • 在从服务器上执行 CHANGE MASTER TO 命令：
CHANGE MASTER TO
    MASTER_HOST = '192.168.1.100',
    MASTER_USER = 'repl_user',
    MASTER_PASSWORD = 'repl_password',
    MASTER_LOG_FILE = 'mysql-bin.000003',
    MASTER_LOG_POS = 120;
  • 配置完成后，启动从服务器的复制功能：
START SLAVE;
  • 可以通过 SHOW SLAVE STATUS \G 命令查看从服务器的复制状态，确保 I/O 线程和 SQL 线程都正常运行：
SHOW SLAVE STATUS \G;
  • 关键的状态信息包括：
    • Slave_IO_Running: Yes 表示 I/O 线程正在运行。
    • Slave_SQL_Running: Yes 表示 SQL 线程正在运行。
    • Seconds_Behind_Master: 0 表示从服务器与主服务器之间没有延迟。

常见问题与解决方法

  1. 连接失败
    • 问题描述：执行 CHANGE MASTER TO 命令后，启动从服务器复制时，I/O 线程无法连接到主服务器，SHOW SLAVE STATUS \G 中 Slave_IO_Running 为 No，错误信息可能为 Can't connect to master 等。
    • 解决方法：
      • 检查网络连接，确保从服务器可以访问主服务器的 IP 和端口，可以使用 ping 命令检查网络连通性，使用 telnet 命令检查端口是否开放，如 telnet 192.168.1.100 3306。
      • 确认 CHANGE MASTER TO 命令中配置的用户名、密码是否正确，在主服务器上可以使用 SELECT user, host FROM mysql.user WHERE user ='repl_user' 检查用户信息。
      • 检查主服务器的防火墙设置，确保 MySQL 服务端口（默认为 3306）已开放。
  2. 同步数据不一致
    • 问题描述：从服务器的 I/O 线程和 SQL 线程都在运行，但数据与主服务器不一致，可能某些操作没有同步过来。
    • 解决方法：
      • 查看 SHOW SLAVE STATUS \G 中的 Last_Error 字段，可能会显示具体的同步错误信息，例如 Duplicate entry 表示可能存在数据重复插入问题，根据错误信息进行针对性解决。
      • 可以尝试重新配置复制，先在从服务器上执行 STOP SLAVE，然后再次执行 CHANGE MASTER TO 命令，确保 MASTER_LOG_FILE 和 MASTER_LOG_POS 配置正确，之后再执行 START SLAVE。
  3. 中继日志清理问题
    • 问题描述：中继日志文件不断增长，占用大量磁盘空间。
    • 解决方法：
      • 可以通过设置 relay_log_purge = 1（默认值）来让从服务器自动清理不再需要的中继日志文件。当 SQL 线程已经应用了中继日志中的所有事件，并且 I/O 线程不再需要这些中继日志文件时，它们会被自动删除。
      • 如果 relay_log_purge 设置为 0，也可以手动删除中继日志文件，但需要谨慎操作，确保不会影响复制功能。可以先停止从服务器的 I/O 线程（STOP SLAVE IO_THREAD），删除中继日志文件，然后再启动 I/O 线程（START SLAVE IO_THREAD）。

CHANGE MASTER TO 命令在不同场景下的应用

  1. 初次配置主从复制
    • 在搭建新的主从复制环境时，使用 CHANGE MASTER TO 命令配置从服务器连接主服务器的基本信息以及起始同步位置。这是最常见的应用场景，确保从服务器能够准确地从主服务器同步数据。
  2. 主从复制故障恢复
    • 当主从复制出现故障，如主服务器重启、网络中断导致复制中断后，需要在从服务器上重新配置复制。通过获取主服务器当前的二进制日志文件名和位置偏移量（使用 SHOW MASTER STATUS），在从服务器上执行 CHANGE MASTER TO 命令，指定正确的起始位置，然后重新启动复制，使从服务器恢复同步。
  3. 切换主服务器
    • 在一些情况下，可能需要将从服务器切换到另一个主服务器。例如，原主服务器需要进行维护升级，或者进行架构调整。此时，在从服务器上执行 CHANGE MASTER TO 命令，重新配置新主服务器的连接信息和起始同步位置，然后启动复制，从服务器就会开始从新的主服务器同步数据。

与其他复制相关命令的关系

  1. START SLAVE
    • START SLAVE 命令用于启动从服务器的 I/O 线程和 SQL 线程，开始进行复制操作。在执行 CHANGE MASTER TO 命令配置好从服务器的复制参数后，需要执行 START SLAVE 命令才能真正启动复制过程。例如：
CHANGE MASTER TO ...;
START SLAVE;
  1. STOP SLAVE
    • STOP SLAVE 命令用于停止从服务器的 I/O 线程和 SQL 线程，暂停复制操作。在进行一些复制配置修改（如再次执行 CHANGE MASTER TO 命令）或者进行故障排查时，可能需要先停止复制，操作完成后再重新启动。例如：
STOP SLAVE;
CHANGE MASTER TO ...;
START SLAVE;
  1. SHOW SLAVE STATUS
    • SHOW SLAVE STATUS 命令用于查看从服务器的复制状态，包括 I/O 线程和 SQL 线程的运行情况、与主服务器的延迟情况、当前同步的二进制日志位置等重要信息。在执行 CHANGE MASTER TO 命令和启动复制后，通过查看这个命令的输出可以确认复制是否正常工作。例如：
SHOW SLAVE STATUS \G;
  • 输出结果包含大量的复制相关信息，如 Seconds_Behind_Master 字段表示从服务器相对于主服务器的延迟时间（秒），Relay_Master_Log_File 表示当前正在同步的主服务器二进制日志文件名等。

性能影响与优化

  1. 网络性能影响
    • 从服务器与主服务器之间的网络性能对复制有重要影响。如果网络带宽不足或者网络延迟高，会导致 I/O 线程从主服务器获取二进制日志事件的速度变慢，从而影响数据同步的实时性。
    • 优化方法：
      • 确保主从服务器之间的网络带宽充足，可以通过网络测试工具（如 iperf）来测试带宽。如果带宽不足，考虑升级网络设备或网络服务。
      • 减少网络延迟，优化网络拓扑结构，尽量减少网络跳数。可以通过 traceroute 命令查看网络路径，找出可能存在延迟的节点并进行优化。
  2. I/O 性能影响
    • 从服务器上的磁盘 I/O 性能会影响中继日志的写入和读取速度，进而影响复制性能。如果磁盘 I/O 繁忙，可能导致 I/O 线程写入中继日志缓慢，或者 SQL 线程读取中继日志延迟。
    • 优化方法：
      • 选择性能较好的磁盘，如 SSD 磁盘，相比传统机械硬盘，SSD 具有更快的读写速度。
      • 合理配置中继日志文件的存储位置，避免与其他 I/O 繁忙的文件系统共享磁盘。可以将中继日志存储在专门的磁盘分区上。
      • 调整 MariaDB 的相关配置参数，如 innodb_log_file_size、innodb_flush_log_at_trx_commit 等，优化 InnoDB 存储引擎的 I/O 性能，因为 InnoDB 存储引擎在复制过程中也会涉及大量的 I/O 操作。
  3. CPU 性能影响
    • SQL 线程在重放中继日志事件时需要消耗 CPU 资源，如果从服务器的 CPU 性能不足，可能导致事件重放速度变慢，从而使从服务器与主服务器之间产生延迟。
    • 优化方法：
      • 确保从服务器有足够的 CPU 资源，可以通过系统监控工具（如 top 命令）查看 CPU 使用情况。如果 CPU 使用率过高，考虑优化服务器上其他占用 CPU 资源的进程，或者升级服务器硬件配置。
      • 对于复杂的 SQL 语句重放，可以考虑对数据库架构和查询进行优化，减少 SQL 执行的复杂度，从而降低 CPU 消耗。例如，对大表进行分区，优化索引等。

安全性考虑

  1. 复制用户权限
    • 用于复制的用户（在 CHANGE MASTER TO 命令中配置的 MASTER_USER）应仅授予 REPLICATION SLAVE 权限，避免赋予过多不必要的权限。这样可以减少潜在的安全风险，防止恶意用户利用复制用户进行非法操作。
    • 在主服务器上创建复制用户时，应遵循最小权限原则，例如：
CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;
  1. 密码安全
    • CHANGE MASTER TO 命令中配置的 MASTER_PASSWORD 应设置为强密码，包含字母、数字、特殊字符等，并且定期更换密码。同时，要注意密码在配置文件和命令行中的存储安全，避免密码泄露。
    • 如果在配置文件中存储密码，应确保配置文件的访问权限设置合理，只有 MariaDB 服务相关的用户可以读取。例如，在 Linux 系统上，配置文件的权限可以设置为 600，只允许文件所有者读取和写入。
  2. SSL 连接
    • 如果主从服务器之间的网络环境存在安全风险，可以启用 SSL 连接来加密数据传输。在 CHANGE MASTER TO 命令中可以配置 SSL 相关参数，如 MASTER_SSL = 1，MASTER_SSL_CA = 'ca_file_path' 等。
    • 主服务器需要配置相应的 SSL 证书和密钥，从服务器使用 CA 证书来验证主服务器的身份，确保连接的安全性。例如，在主服务器的配置文件（my.cnf）中添加以下配置：
[mysqld]
ssl-ca=/path/to/ca.crt
ssl-cert=/path/to/server.crt
ssl-key=/path/to/server.key
  • 在从服务器执行 CHANGE MASTER TO 命令时：
CHANGE MASTER TO
    ...
    MASTER_SSL = 1,
    MASTER_SSL_CA = '/path/to/ca.crt';

通过深入理解 CHANGE MASTER TO 命令的工作原理、在不同场景下的应用以及相关的性能优化和安全考虑，数据库管理员和开发人员能够更好地搭建、维护和优化 MariaDB 的主从复制环境，确保数据的一致性和系统的高可用性。