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

MySQL复制与集群技术解析

2022-11-296.7k 阅读

MySQL 复制技术概述

MySQL 复制是一种将一台 MySQL 服务器（主服务器，Master）的数据变更同步到一台或多台其他 MySQL 服务器（从服务器，Slave）的技术。它基于二进制日志（Binary Log）来实现数据的复制。主服务器将数据变更记录到二进制日志中，从服务器通过读取主服务器的二进制日志并在本地重放这些日志来实现数据的同步。

复制的工作原理

  1. 主服务器的操作：当主服务器上的数据发生改变，例如执行了 INSERT、UPDATE 或 DELETE 语句，这些变更会被记录到二进制日志（binlog）中。
  2. 从服务器的操作：从服务器有两个线程参与复制过程，分别是 I/O 线程和 SQL 线程。I/O 线程负责从主服务器读取二进制日志，并将其写入到本地的中继日志（relay log）中。SQL 线程则负责读取中继日志，并按照日志中的记录在从服务器上重放，从而使从服务器的数据与主服务器保持一致。

复制的模式

  1. 基于语句的复制（Statement - Based Replication，SBR）：主服务器将执行的 SQL 语句记录到二进制日志中，从服务器通过重放这些语句来实现数据同步。这种模式的优点是日志文件较小，因为只记录语句而不是数据的实际变化。但是，对于一些具有不确定性的函数（如 NOW()、RAND() 等），在主从服务器上执行可能会产生不同的结果。
  2. 基于行的复制（Row - Based Replication，RBR）：主服务器将数据行的实际变化记录到二进制日志中，从服务器通过应用这些行的变化来实现数据同步。这种模式能确保主从服务器数据的一致性，尤其适用于包含不确定函数的操作。缺点是日志文件通常较大，因为要记录每行数据的变化。
  3. 混合模式复制（Mixed - Based Replication，MBR）：结合了 SBR 和 RBR 的优点，MySQL 会根据执行的 SQL 语句自动选择合适的复制模式。对于大多数语句，使用 SBR 以减少日志量；对于包含不确定函数的语句，使用 RBR 以确保数据一致性。

MySQL 复制的配置

主服务器配置

  1. 启用二进制日志：在 MySQL 配置文件（通常是 my.cnf 或 my.ini）中添加或修改以下配置：
[mysqld]
log - bin = /var/log/mysql/mysql - bin.log
server - id = 1

这里 log - bin 指定了二进制日志的路径和文件名前缀，server - id 是服务器的唯一标识，在复制环境中每个服务器都必须有唯一的 server - id。重启 MySQL 服务使配置生效。

  1. 创建复制用户：登录到主服务器的 MySQL 命令行，执行以下语句创建一个用于从服务器连接的用户：
CREATE USER'replication_user'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO'replication_user'@'%';
FLUSH PRIVILEGES;

这里创建了一个名为 replication_user 的用户，并赋予其复制相关的权限，'%' 表示允许任何 IP 地址的从服务器连接。

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

输出类似如下：

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

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

从服务器配置

  1. 设置服务器 ID：在 MySQL 配置文件中设置 server - id，确保与主服务器的 server - id 不同：
[mysqld]
server - id = 2

重启 MySQL 服务。

  1. 配置主服务器连接：登录到从服务器的 MySQL 命令行，执行以下语句配置主服务器连接信息：
CHANGE MASTER TO
    MASTER_HOST ='master_host_ip',
    MASTER_USER ='replication_user',
    MASTER_PASSWORD = 'password',
    MASTER_LOG_FILE ='mysql - bin.000003',
    MASTER_LOG_POS = 154;

这里 MASTER_HOST 是主服务器的 IP 地址，MASTER_USER 和 MASTER_PASSWORD 是在主服务器创建的复制用户及密码，MASTER_LOG_FILE 和 MASTER_LOG_POS 是之前在主服务器获取的值。

  1. 启动复制：执行以下命令启动从服务器的复制功能：
START SLAVE;
  1. 检查复制状态：执行以下命令检查从服务器的复制状态：
SHOW SLAVE STATUS \G;

重点关注 Slave_IO_Running 和 Slave_SQL_Running 字段，两者都应为 Yes，并且 Seconds_Behind_Master 字段表示从服务器落后主服务器的时间，正常情况下该值应为 0 或接近 0。如果有问题，可以查看 Last_IO_Error 和 Last_SQL_Error 字段获取错误信息。

MySQL 复制的常见问题及解决方法

主从延迟

  1. 原因：
    • 从服务器硬件性能不足，无法及时处理中继日志中的事务。
    • 主服务器负载过高，导致二进制日志生成速度过快，从服务器来不及同步。
    • 网络延迟或不稳定，影响从服务器读取主服务器的二进制日志。
    • 复杂的事务或大事务在主服务器执行，从服务器重放这些事务需要较长时间。
  2. 解决方法：
    • 提升从服务器的硬件配置，例如增加 CPU、内存等资源。
    • 优化主服务器的负载，如合理配置数据库参数、优化查询等。
    • 检查网络连接，确保网络稳定，并适当调整网络相关参数。
    • 尽量避免在主服务器执行大事务，将大事务拆分成多个小事务执行。

复制错误

  1. 原因：
    • 主从服务器数据不一致，例如在从服务器手动修改了数据，导致与主服务器数据冲突。
    • 主服务器上执行了不支持复制的操作，如某些存储过程或函数在主从服务器上的实现不一致。
    • 二进制日志损坏或丢失。
  2. 解决方法：
    • 如果是数据不一致问题，可以通过重新搭建从服务器，确保从服务器从主服务器的初始状态开始同步。
    • 对于不支持复制的操作，需要检查并修改相关代码，确保主从服务器操作的一致性。
    • 如果二进制日志损坏或丢失，可以尝试从备份中恢复主服务器，并重新配置复制。

MySQL 集群技术概述

MySQL 集群是一种将多个 MySQL 服务器节点组合在一起，以提供高可用性、可扩展性和高性能的技术。MySQL 集群通常由管理节点（Management Node）、数据节点（Data Node）和 SQL 节点（SQL Node，也称为 MySQL Server Node）组成。

集群的工作原理

  1. 管理节点：负责管理集群的配置信息，包括数据节点和 SQL 节点的位置、数量等。管理节点还负责监控集群的状态，当有节点出现故障时，管理节点会协调其他节点进行故障恢复。
  2. 数据节点：存储实际的数据，并负责数据的复制和冗余。MySQL 集群采用分布式存储方式，数据被自动分片存储在多个数据节点上，同时每个数据片段会有多个副本存储在不同的数据节点上，以提供数据的高可用性。
  3. SQL 节点：接收客户端的 SQL 请求，将其路由到相应的数据节点进行处理，并将处理结果返回给客户端。SQL 节点不存储数据，只是作为数据访问的入口。

集群的优点

  1. 高可用性：由于数据在多个节点上有副本，当某个节点出现故障时，其他节点可以继续提供服务，确保系统的可用性。
  2. 可扩展性：可以通过添加更多的数据节点或 SQL 节点来扩展集群的存储能力和处理能力，以满足不断增长的业务需求。
  3. 高性能：分布式存储和并行处理机制使得 MySQL 集群能够快速处理大量的并发请求，提高系统的性能。

MySQL 集群的配置（以 NDB Cluster 为例）

管理节点配置

  1. 安装 MySQL 集群软件包：根据操作系统的不同，安装相应的 MySQL 集群软件包。例如在 Ubuntu 系统上，可以使用以下命令安装：
sudo apt - get install mysql - cluster - ndb - 8.0
  1. 创建配置文件：在管理节点上创建 config.ini 文件，内容如下：
[ndb default]
NoOfReplicas = 2

[ndb_mgmd default]
NodeId = 1

[ndb_mgmd]
NodeId = 1
Address = 192.168.1.100

[ndb_mgmd]
NodeId = 2
Address = 192.168.1.101

[data default]
NodeGroup = 0

[data]
NodeId = 3
NodeGroup = 0
Address = 192.168.1.110

[data]
NodeId = 4
NodeGroup = 0
Address = 192.168.1.111

[mysqld default]

[mysqld]
NodeId = 50
HostName = 192.168.1.120

[mysqld]
NodeId = 51
HostName = 192.168.1.121

这里 NoOfReplicas 表示数据副本的数量，ndb_mgmd 部分定义了管理节点的信息，data 部分定义了数据节点的信息，mysqld 部分定义了 SQL 节点的信息。

  1. 启动管理节点：执行以下命令启动管理节点：
ndb_mgmd - f /var/lib/mysql-cluster/config.ini --initial

数据节点配置

  1. 安装 MySQL 集群软件包：与管理节点类似，在数据节点上安装 MySQL 集群软件包。
  2. 配置数据节点：在数据节点上创建 config.ini 文件，内容与管理节点的 config.ini 文件相同。
  3. 启动数据节点：执行以下命令启动数据节点：
ndb_node - id = 3 /var/lib/mysql - cluster/config.ini

这里 3 是数据节点的 NodeId，根据实际情况修改。

SQL 节点配置

  1. 安装 MySQL 服务器：在 SQL 节点上安装 MySQL 服务器，例如在 Ubuntu 系统上：
sudo apt - get install mysql - server
  1. 配置 MySQL 服务器：在 MySQL 配置文件（my.cnf 或 my.ini）中添加以下配置：
[mysqld]
ndbcluster
ndb - mgm - node = 192.168.1.100
ndb - mgm - node = 192.168.1.101

这里指定了管理节点的地址。 3. 重启 MySQL 服务：使配置生效。

MySQL 集群的管理与维护

查看集群状态

在管理节点上执行以下命令查看集群状态：

ndb_mgmd - e "show"

输出类似如下：

Cluster Configuration
---------------------
[ndb_mgmd default (Version: 8.0.26)]
Node 1: started (mysql - cluster - ndb - 8.0.26)
Node 2: started (mysql - cluster - ndb - 8.0.26)

[ndb_mgmd]
Node 1: started (mysql - cluster - ndb - 8.0.26)
Node 2: started (mysql - cluster - ndb - 8.0.26)

[data default (Version: 8.0.26)]

[data]
Node 3: started (mysql - cluster - ndb - 8.0.26)
Node 4: started (mysql - cluster - ndb - 8.0.26)

[mysqld default]

[mysqld]
Node 50: started (mysql - server - 8.0.26)
Node 51: started (mysql - server - 8.0.26)

通过该命令可以查看各个节点的状态，确保集群正常运行。

节点故障处理

  1. 管理节点故障：如果一个管理节点出现故障，另一个管理节点可以继续管理集群。可以在故障节点修复后，重新启动该管理节点，它会自动加入集群。
  2. 数据节点故障：由于数据有副本，单个数据节点故障通常不会影响集群的正常运行。可以在故障节点修复后，重新启动该数据节点，集群会自动同步数据。
  3. SQL 节点故障：SQL 节点故障不会影响数据的存储和其他 SQL 节点的正常工作。修复故障 SQL 节点后，重启 MySQL 服务即可使其重新加入集群。

MySQL 复制与集群技术的选择与应用场景

选择依据

  1. 数据一致性要求：如果对数据一致性要求极高，如金融领域的交易数据，基于行的复制或 MySQL 集群更合适，因为它们能更好地保证数据的一致性。而基于语句的复制在某些情况下可能会因为函数的不确定性导致数据不一致。
  2. 性能与可扩展性：对于高并发、大数据量的场景，MySQL 集群更具优势，它可以通过增加节点来扩展性能和存储能力。MySQL 复制虽然也能在一定程度上提高读性能，但在扩展性方面相对有限。
  3. 成本与复杂度：MySQL 复制的配置和维护相对简单，成本较低，适合对成本敏感且数据量和并发量不是特别高的场景。MySQL 集群的配置和管理较为复杂，成本也较高，适合对高可用性、高性能和可扩展性有严格要求的企业级应用。

应用场景

  1. MySQL 复制的应用场景：
    • 数据备份与恢复：通过复制可以将主服务器的数据实时备份到从服务器，当主服务器出现故障时，可以快速切换到从服务器，减少数据丢失的风险。
    • 读写分离：将读操作分配到从服务器，减轻主服务器的负载，提高系统的整体性能。例如，在新闻网站、论坛等读多写少的应用中，这种方式非常有效。
  2. MySQL 集群的应用场景：
    • 电商平台：电商平台通常有大量的并发访问和数据存储需求，MySQL 集群的高可用性、可扩展性和高性能能够满足其业务需求，确保系统在高流量下的稳定运行。
    • 在线游戏：在线游戏对实时性和数据一致性要求较高，同时需要处理大量的并发玩家请求，MySQL 集群可以提供稳定可靠的数据存储和处理服务。

在实际应用中，应根据具体的业务需求、预算和技术团队的能力等因素，综合选择合适的技术方案。同时，还可以将 MySQL 复制和集群技术结合使用，以充分发挥两者的优势。例如，在集群内部采用复制技术来进一步提高数据的冗余和可用性，或者在复制的基础上，逐步扩展为集群以满足业务增长的需求。