Practical MySQL & MariaDB

MySQL 复制详解：部署、GTID、监控与故障排除指南

進階／其他

.

目次

1. 什么是 MySQL 复制？概述与使用场景

MySQL 复制是一项功能，可实时将数据库的副本同步到其他服务器。这提升了数据库的冗余性和性能。下面，我们将详细说明 MySQL 复制的使用时机以及其工作原理。

MySQL 复制概述

MySQL 复制通过 主服务器 和一个或多个 从服务器 在多台服务器之间共享数据库内容。具体而言，记录在主服务器二进制日志中的数据更新会被从服务器读取并应用，从而保持数据同步。这使得在主服务器出现故障时可以切换到从服务器，实现服务连续性。

MySQL 复制的使用场景

MySQL 复制在以下场景中被广泛使用：

  • 高可用性：在故障发生时，切换到从服务器可将停机时间降至最低。
  • 负载均衡：只读查询可以分发到从服务器，减轻主服务器的负载。
  • 数据保护与备份：由于复制实时复制数据，它也可以作为备份机制使用。

复制类型

MySQL 复制根据同步方式包含以下类型：

  • 异步复制：主服务器在不等待从服务器确认的情况下继续执行。这可以实现更快的响应时间，但在故障时可能会有部分数据未到达从服务器。
  • 半同步复制：主服务器在继续执行前会等待从服务器确认已收到数据。这比异步复制提供更高的可靠性，但响应时间略有下降。

下一节将解释 MySQL 复制的基本概念，包括二进制日志和 GTID。

2. MySQL 复制的基本概念

要理解 MySQL 复制，必须掌握 二进制日志 和 GTID（全局事务 ID） 的作用，它们在复制过程中扮演关键角色。这些要素构成了准确数据复制的基础。

主从角色

在 MySQL 复制中，主服务器 与 从服务器 各自承担不同职责。主服务器将数据更新记录到二进制日志并发送给从服务器。从服务器则应用接收到的日志以更新自身数据。因此，从服务器保持与主服务器相同的数据状态。

二进制日志与中继日志

MySQL 复制依赖以下两种日志：

  1. 二进制日志
  • 二进制日志记录主服务器上的数据更新（如 INSERT、UPDATE、DELETE），从而使从服务器能够保持与主服务器相同的数据状态。
  1. 中继日志
  • 中继日志存储从服务器从主服务器接收到的二进制日志事件。从服务器的 SQL 线程按顺序执行中继日志，以应用数据变更。

什么是 GTID（全局事务 ID）？

GTID 是一种为每个事务分配唯一 ID 的机制，帮助在多个从服务器之间保持一致性。使用 GTID 后，无需再指定二进制日志位置。只有尚未从主服务器获取的事务会自动应用到从服务器，大大简化了管理工作。

GTID 的优势

  • 唯一标识：每个事务都有唯一的 GTID，能够清晰地标识已应用的事务。
  • 更易恢复：使用 GTID 时，主从重启后仅重新处理未应用的事务。
  • 高效的运维管理：即使在拥有多台从服务器的大规模环境中，也能通过简化的管理保持事务一致性。

要使用 GTID，需要将 gtid_mode=ON 和 enforce_gtid_consistency=ON 两项设置打开。分别在主服务器和从服务器上配置这些设置，即可实现基于 GTID 的复制。

下一节将说明设置 MySQL 复制的具体步骤。

3. MySQL 复制设置步骤

本节说明设置 MySQL 复制所需的步骤。按照这些步骤，您可以配置基本的主从结构并实现实时数据同步。

配置主服务器

首先，编辑主服务器的配置文件（通常是 my.cnf 或 my.ini），以启用二进制日志并设置服务器 ID。

  1. 编辑配置文件
  • 在 [mysqld] 部分下添加以下设置，并设置唯一的服务器 ID（例如，1）。
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id 必须是每台服务器唯一的数字，log-bin 用于启用二进制日志。
  1. 创建复制用户
  • 在主服务器上创建专用的复制用户并授予必要的权限。
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • 该用户用于从服务器访问主服务器的数据。
  1. 检查主服务器状态
  • 检查当前的二进制日志文件和位置（日志位置）。在配置从服务器时需要此信息。
    SHOW MASTER STATUS;
  • 此命令显示的 File（日志文件名）和 Position 将在从服务器配置中使用。

配置从服务器

接下来，编辑从服务器的配置文件并配置服务器 ID 与主服务器信息。

  1. 编辑配置文件
  • 在从服务器上同样设置唯一的 server-id（例如，2）。该值必须与主服务器的服务器 ID 不同。
    [mysqld]
server-id=2
  • 通常还会将 read_only=ON 设置为只读，以防止在从服务器上写入数据。
  1. 在从服务器上配置主服务器信息
  • 在从服务器上执行以下命令，指定主服务器的主机名、用户、二进制日志文件名和位置。
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • 输入之前在主服务器上确认的 MASTER_LOG_FILE 和 MASTER_LOG_POS 值。
  1. 启动复制
  • 在从服务器上运行以下命令以启动复制。
    START SLAVE;

验证复制状态

验证主从之间的复制是否配置正确。

  • 检查主服务器状态
    SHOW MASTER STATUS;
  • 检查从服务器状态
    SHOW SLAVE STATUS\G;
  • 如果 Slave_IO_Running 和 Slave_SQL_Running 均显示 Yes，则复制正常运行。

下一节将说明高级复制配置，包括异步复制与半同步复制的区别以及使用 GTID 的设置方式。

4. 复制类型与高级用法

MySQL 复制根据数据同步方式主要分为两类：异步复制 和 半同步复制。了解它们的特性并根据实际场景选择，可提升系统性能和可靠性。本节还将解释在复制配置中使用 GTID（全局事务标识符） 的优势。

异步复制与半同步复制的区别

1. 异步复制

在异步复制中，主服务器在事务完成后立即向客户端返回响应。换句话说，即使同步到从服务器被延迟，主服务器仍可继续处理新请求。这提供了极佳的响应性能，适用于侧重负载分担的系统。但在故障发生时，尚未同步到从服务器的数据可能会丢失，存在风险。

2. 半同步复制

在半同步复制中，主服务器仅在确认数据传输到从服务器完成后，才向客户端返回响应。这提高了数据一致性，但由于等待从服务器，事务响应时间可能会增加。半同步复制非常适合需要高数据一致性的系统或数据可靠性是首要考虑的环境。

使用 GTID 的复制

GTID（Global Transaction Identifier，全局事务标识符）为每个事务分配一个唯一的 ID，并在主从之间维护事务一致性。启用 GTID 比传统的基于二进制日志位置的复制更容易管理复制。

GTID 的优势

  • 改进的数据一致性 : 使用 GTID，从服务器可以自动识别尚未应用的交易，从而更容易保持一致性。
  • 简化复制管理 : GTID 提高了故障转移、主从切换和恢复任务的效率。因为不再需要指定二进制日志位置，操作变得更简单。

GTID 复制配置

要使用 GTID，必须在主服务器和从服务器的配置文件中添加并启用以下选项。

主服务器配置

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

从服务器配置

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

在启用 GTID 的环境中，只需使用 CHANGE MASTER TO 命令在从服务器上设置主服务器信息，即可通过 GTID 自动执行复制。

下一节将解释 MySQL 复制的维护方法以及运营管理中的关键监控点。

5. 复制的维护和监控

要正确操作 MySQL 复制，定期维护和监控是必不可少的。本节解释了检查复制是否正常运行的命令以及如何处理常见错误。

如何检查复制状态

使用以下命令检查主从之间的同步状态。

检查主状态

您可以使用 SHOW MASTER STATUS 命令验证主服务器的复制状态。此命令显示当前二进制日志文件名和位置，允许您确认应传递给从服务器的最新更新。

SHOW MASTER STATUS;

输出通常包括以下字段：

  • File : 主服务器生成当前二进制日志文件名
  • Position : 二进制日志中的当前位置
  • Binlog_Do_DB 和 Binlog_Ignore_DB : 包含/排除在复制中的数据库

检查从状态

您可以使用 SHOW SLAVE STATUS 命令检查从服务器的复制状态。结果包括确定从服务器是否正确运行所需的信息。

SHOW SLAVE STATUS\G;

关键字段包括：

  • Slave_IO_Running 和 Slave_SQL_Running : 如果两者均为 Yes，则从服务器运行正常。
  • Seconds_Behind_Master : 表示从服务器落后主服务器的程度（以秒为单位）。理想情况下，此值应为 0。

复制故障排除

复制操作期间的常见问题包括连接错误和数据不一致。下面是典型错误情况以及如何处理它们。

1. 连接错误

如果 Slave_IO_Running 为 No，则表示从服务器无法连接到主服务器。请尝试以下操作：

  • 验证主服务器主机名或 IP 地址 : 确保主服务器地址正确。
  • 检查防火墙设置 : 确认所需端口（通常为 3306）已打开。

2. 数据不一致

.如果 Last_Error 包含错误信息，可能已经在主库和从库之间出现了数据不一致的情况。在这种情况下，请停止从库并在重新启动复制之前进行修正。

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. 减少复制延迟

复制延迟可能由从库硬件限制或网络问题引起。如有必要，升级从库服务器配置可以提升性能。

下一节将更详细地探讨复制问题并提供进一步的解决方案。

6. 常见问题及其解决方案

在 MySQL 复制过程中，可能会出现各种问题。本节解释常见问题及其解决办法。及早发现问题并采取正确的修复措施有助于保持系统的稳定运行。

1. 当 Slave_IO_Running 停止时

症状：如果在 SHOW SLAVE STATUS 的输出中 Slave_IO_Running 显示为 No，则从库无法连接到主库。

原因与解决方案：

  • 网络问题：如果存在网络连通性问题，从库将无法访问主库。检查防火墙设置并确认主库可达。
  • 主机名或 IP 地址错误：确认在 CHANGE MASTER TO 中指定的主机名或 IP 地址是否正确。
  • 用户权限问题：如果主库上的复制用户权限不足，连接将失败。使用 GRANT REPLICATION SLAVE 确认已授予正确的权限。

2. 从库数据不一致

症状：如果主库和从库之间的数据不匹配，从库可能会进入不一致状态。

原因与解决方案：

  • 手动数据修正：停止从库，手动修复有问题的事务，然后重新启动复制。STOP SLAVE; # 如有必要修复数据 START SLAVE;
  • 重新同步：如果不一致规模较大，需从主库进行完整备份并重新同步从库。

3. 复制延迟

症状：如果在 SHOW SLAVE STATUS 的输出中 Seconds_Behind_Master 不为 0，则从库落后于主库。理想情况下，该值应尽可能接近 0。

原因与解决方案：

  • 从库硬件限制：如果从库服务器资源不足，可能跟不上复制。升级硬件可能有效。
  • 查询优化：如果从主库接收的查询在从库上执行时间过长，会导致复制延迟。添加索引并优化查询可以缩短处理时间。

4. 复制用户权限错误

症状：如果 Last_Error 显示权限相关的错误信息，从库可能没有足够的权限连接到主库。

原因与解决方案：

  • 重新配置用户权限：确保主库上存在具有相应权限的用户。必要时重新配置。GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. 二进制日志增长

症状：主库的二进制日志可能会过度增长，消耗磁盘空间。

原因与解决方案：

  • 二进制日志轮转：定期删除或归档二进制日志以防止过度增长。通过配置 expire_logs_days，可以自动删除超过指定天数的日志。SET GLOBAL expire_logs_days = 7; # 删除 7 天前的日志

通过了解这些常见的 MySQL 复制问题及其解决方案，您可以确保更顺畅的运维管理。下一节将总结复制管理的关键要点。

7. 结论

.MySQL 复制是提升数据一致性和系统可靠性的关键特性。在本文中，我们涵盖了从 MySQL 复制的基本概念到设置步骤、监控实践以及故障排除方法的全部内容。以下是有效复制管理的关键要点摘要。

关键要点

  1. 选择合适的复制类型 * 异步复制提供更快的响应时间，适合负载分配。然而，如果可靠性是首要考虑，半同步复制更为合适。请根据系统需求进行选择。

  2. 有效使用 GTID * GTID 免除了指定二进制日志位置的需求，并实现了事务管理的平滑化。它在拥有多个从库或故障转移至关重要的环境中尤为有用。

  3. 定期状态监控 * 使用 SHOW MASTER STATUS 和 SHOW SLAVE STATUS 定期监控主从服务器的运行状态。及时对异常进行处理，可将数据不一致或延迟等风险降至最低。

  4. 掌握基础故障排除 * 常见的复制问题包括从库连接错误、数据不一致以及延迟。了解每个问题的基本解决方案，可确保系统更顺畅运行。

  5. 二进制日志管理 * 由于二进制日志可能占用大量磁盘空间，建议配置 expire_logs_days 以实现自动清理，并定期进行维护。

MySQL 复制并非一次性设置任务。持续的监控和恰当的维护至关重要。通过定期审查系统状态并在必要时调整配置，您可以构建并保持高度可靠的数据库系统。

我们希望本指南能帮助您更好地理解和实施 MySQL 复制。祝您复制过程顺畅、稳定。