2.MySQL单库-读写分离集群-分库分表集群-分片算法

Asthenian
101 阅读11分钟

在数据库系统设计中，随着数据量的不断增长和业务需求的多样化，单一的数据库架构往往无法满足高可用、高性能、高扩展等需求。因此，通常采用多种集群架构和中间件来提升系统的能力。你提到的三种常见模式（单库模式、读写分离集群模式、分库分表集群模式）是数据库架构设计中的关键组成部分，下面是对这些模式的完善和扩展说明。

1. 单库模式

单库模式是最基础的数据库架构模式，通常适用于数据量较小、并发量较低的系统。在该模式下，所有的数据存储都集中在一个 MySQL 数据库实例中，所有的读写操作都由这个单一数据库来处理。优点是架构简单，易于管理；但缺点也很明显，随着数据量和并发量的增加，单个数据库实例会面临性能瓶颈，无法应对大规模的流量和数据存储需求。

适用场景：

  • 数据量较小，负载较轻。
  • 系统复杂度较低，开发人员希望架构简单。

缺点：

  • 随着数据量增大，性能瓶颈逐渐显现。
  • 不具备高可用性，一旦数据库故障，系统可能无法恢复。

2. 读写分离集群模式

为了解决单库模式带来的性能瓶颈问题，通常采用读写分离集群模式。该模式的核心思想是将数据库的读操作和写操作分开，由不同的数据库节点来处理。具体来说，系统通过在主数据库（Master）和从数据库（Slave）之间进行数据同步来实现读写分离。主库负责写入操作，而从库负责读取操作，减轻了主库的负担，从而提升了系统的性能和可扩展性。

原理：

  • 主从复制： MySQL 通过 binlog（二进制日志）将主库的更新操作同步到从库。主库一般用于写操作，从库用于读操作。
  • 中间件： 为了实现读写分离，通常会引入中间件（如 Mycat、ShardingSphere 等）来根据不同的业务场景将请求路由到主库或从库。
  • 高可用性： 采用 MHA（MySQL高可用性架构）或 Orchestrator 等中间件来实现故障自动切换。若主库发生故障，可以自动将某个从库提升为新的主库，从而保证系统的高可用性。

优点：

  • 减轻了主库的负担，提高了读操作的吞吐量。
  • 通过主从同步机制，能够实现数据冗余，提高数据的可靠性。
  • 使用中间件可以灵活地将请求路由到不同的数据库，提升了系统的可扩展性。

缺点：

  • 写操作依赖于主库，如果主库宕机，可能会导致写操作的延迟或丢失。
  • 数据同步的延迟可能导致从库的数据略有滞后，影响读取的准确性。

适用场景：

  • 读多写少的应用场景，如电商、新闻网站等。
  • 数据量和流量逐渐增大，但单库仍能承受的情况。

3. 分库分表（分片）集群模式

当系统的负载进一步加大时，单一的数据库无法承载如此庞大的数据量，这时就需要采用分库分表（即分片）架构来水平扩展。分库分表通过将数据分布到多个物理数据库实例中，打破了单个数据库的限制，从而支持大规模的数据存储和高并发的读写操作。

分片的核心概念：

  • 分库： 将数据分布到多个数据库实例中，每个数据库负责一部分数据。通过拆分大表，避免单库的存储限制和性能瓶颈。
  • 分表： 将大表进一步划分为多个小表，减少单个表的数据量，提高查询效率。
  • 分片键（Shard Key）： 根据特定的字段（如用户ID、订单ID等）进行分片，确保数据的均匀分布和查询效率。

分片算法：

  1. 范围法： 根据分片键的值范围将数据划分到不同的库和表中。例如，根据 ID 的大小进行区间划分。范围法易于扩展和理解，适用于大部分场景，但可能导致数据分布不均匀，某些区间的负载可能过高。

    例子：

    • 分片键：user_id
    • 范围：user_id < 1000 分到 shard1，1000 <= user_id < 2000 分到 shard2 等。

  2. 哈希法： 根据分片键对数据进行哈希计算（如取模），将数据均匀地分配到不同的库和表中。哈希法的优点是数据分布均匀，但扩展性较差，因为扩展时可能需要大量的数据迁移。

    例子：

    • 分片键：user_id
    • 哈希：user_id % 3，分别映射到 shard1、shard2、shard3。

  3. 一致性哈希： 一致性哈希是哈希算法的一种变种，主要用于解决分库扩容时数据迁移的难题。它通过哈希环的方式分配数据，在新增或减少分片时，只有少量的数据需要迁移，从而提高了扩展性。

优点：

  • 通过水平拆分，极大地扩展了数据库的存储容量和处理能力。
  • 数据存储分散，降低了单点故障的风险。
  • 在高并发的场景下，能够实现高吞吐量的读写操作。

缺点：

  • 数据跨库、跨表查询复杂，查询性能和开发难度增加。
  • 分片方案设计不当可能导致数据不均匀分布，影响负载均衡。
  • 扩展过程中可能需要迁移大量数据，影响系统稳定性。

适用场景：

  • 数据量极大，无法通过单一数据库进行存储和处理的场景。
  • 需要高并发、高吞吐量处理的系统，如大型电商、社交平台等。

4. 主流模式：读写分离 + 分库分表的组合运用

在实际应用中，读写分离和分库分表通常会结合使用，构成一个更加复杂的集群架构。具体来说：

  • 分库分表解决了单一数据库实例的性能瓶颈和扩展性问题，通过将数据分布到多个数据库节点中，可以承载更大的数据量。
  • 读写分离通过将读操作分发到从库，减轻主库的负担，从而提高系统的整体性能。

结合方式：

  • 在每个分片（分库）内，使用读写分离架构，主库负责写操作，从库负责读操作。
  • 通过中间件（如 ShardingSphere 或 Mycat），负责将请求路由到正确的分片和对应的读写分离节点。

优点：

  • 系统可扩展性强，能够应对大规模数据和高并发读写的需求。
  • 通过分片和读写分离的结合，既保证了数据存储的扩展性，又提高了系统的读写性能。

缺点：

  • 架构复杂度较高，需要精心设计分片策略、数据路由策略和容错机制。
  • 开发和维护的成本增加。

适用场景：

  • 数据量庞大，且系统需要处理大量的读请求的高并发系统，如大型电商平台、社交网站、金融系统等。

总结

随着业务的不断发展，数据库架构也需要不断地调整和优化。不同的架构模式适用于不同的场景：

  • 单库模式适用于简单、小规模的应用。
  • 读写分离模式适用于读多写少的场景，能有效提升读取性能。
  • 分库分表模式适用于数据量极大、需要水平扩展的系统。
  • 读写分离 + 分库分表组合模式适用于高并发、大数据量的复杂应用，既保证了扩展性，又提升了性能。

选择合适的架构模式需要综合考虑业务需求、系统规模、可维护性以及未来的扩展需求。 配置 MHA（MySQL High Availability） 主要涉及以下几个步骤，包括安装 MHA 相关组件、配置 MySQL 主从复制、配置 MHA 管理器、以及测试高可用性配置。下面是详细的配置过程。

1. 准备 MySQL 环境

首先，确保你已经有一个 MySQL 环境，并且至少有两个 MySQL 实例（一个主库和一个从库）。MHA 的核心依赖于 MySQL 的主从复制。

1.1 安装 MySQL

在每台服务器上安装 MySQL。假设你有两台服务器：

  • 主库服务器：master-host
  • 从库服务器：slave1-host，slave2-host

安装 MySQL 的版本建议与 MHA 兼容，通常是 5.6 或 5.7。安装过程根据操作系统不同而有所区别。

2. 配置 MySQL 主从复制

2.1 主库配置

在主库上进行以下配置：

  1. 编辑 my.cnf 配置文件，启用二进制日志（binlog）和服务器 ID（server-id）。
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = row
  1. 重启 MySQL 服务，使配置生效。
systemctl restart mysql
  1. 创建复制用户并授予权限：
CREATE USER 'replica_user'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;

2.2 从库配置

在从库上进行以下配置：

  1. 编辑 my.cnf 配置文件，设置唯一的 server-id，并启用复制。
[mysqld]
server-id = 2  # 对于每台从库，确保 ID 唯一
  1. 重启 MySQL 服务。
systemctl restart mysql
  1. 配置从库连接到主库：
CHANGE MASTER TO 
  MASTER_HOST = 'master-host', 
  MASTER_USER = 'replica_user', 
  MASTER_PASSWORD = 'password', 
  MASTER_LOG_FILE = 'mysql-bin.000001',  -- 从主库的二进制日志文件名
  MASTER_LOG_POS = 154;                  -- 从主库获取日志位置
START SLAVE;
  1. 检查从库是否同步：
SHOW SLAVE STATUS\G

确保 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes，表示从库正常同步主库。

3. 安装 MHA 组件

MHA 需要在管理节点（MHA Manager）和数据库节点（MySQL 实例）上安装相关软件。

3.1 安装 MHA Manager

MHA Manager 是负责监控 MySQL 主库状态、执行故障转移等操作的核心组件。你需要在管理服务器上安装 MHA Manager。

  1. 安装依赖：
sudo apt-get install perl libdbi-perl libmysqlclient-dev libssh2-1-dev
  1. 下载并安装 MHA：
wget https://github.com/yoshinori-ikegami/mha4mysql-manager/releases/download/v0.57/mha4mysql-manager-0.57.tar.gz
tar -xzvf mha4mysql-manager-0.57.tar.gz
cd mha4mysql-manager-0.57
perl Makefile.PL
make
sudo make install

3.2 配置 MHA Manager

MHA Manager 配置文件通常位于 /etc/mha.cnf。你需要设置以下内容：

[server default]
# MHA Manager 配置的全局设置
manager_user=root
manager_password=yourpassword
ssh_user=root
# 配置 MHA Manager 服务器列表
master_ip_failover_script=/usr/local/bin/master_ip_failover
# 配置 MySQL 节点
[server1]
hostname=master-host
port=3306
candidate_master=1
# 配置从库
[server2]
hostname=slave1-host
port=3306
candidate_master=1
# 其他从库配置
[server3]
hostname=slave2-host
port=3306
candidate_master=0
  • manager_user 和 manager_password：用于 MHA 管理工具连接到 MySQL 的用户名和密码。
  • master_ip_failover_script：定义故障转移时的 IP 切换脚本路径（通常使用 master_ip_failover 脚本）。
  • hostname 和 port：列出所有 MySQL 服务器的信息。
  • candidate_master=1：标记该服务器为故障转移的候选主库。

3.3 配置 SSH 和密钥

MHA Manager 需要通过 SSH 连接到所有 MySQL 节点。你需要确保 MHA Manager 机器能够无密码登录到所有 MySQL 节点。

  1. 生成 SSH 密钥：
ssh-keygen -t rsa
  1. 将公钥拷贝到所有 MySQL 节点：
ssh-copy-id user@master-host
ssh-copy-id user@slave1-host
ssh-copy-id user@slave2-host

4. 启动 MHA

启动 MHA Manager 后，它将开始监控 MySQL 集群，并根据需要进行故障转移。

  1. 启动 MHA Manager：
masterha_manager --conf=/etc/mha.cnf --ignore_last_failover
  1. 查看故障转移状态：
masterha_check_repl --conf=/etc/mha.cnf

该命令将检查 MySQL 集群的复制状态，确保所有节点都同步并且可以正常工作。

5. 测试 MHA 故障转移

为了测试 MHA 是否工作正常，你可以手动停止主库 MySQL 服务，查看是否能够自动切换到从库。

  1. 停止主库：
systemctl stop mysql
  1. 查看 MHA 是否执行故障转移，主库会自动切换到新的主库。
masterha_check_repl --conf=/etc/mha.cnf

如果配置正确，MHA 会自动将新的从库提升为主库，并且所有的 MySQL 节点会重新同步。

6. 优化和维护

  • 定期检查 MHA 状态：定期使用 masterha_check_repl 检查 MySQL 集群的状态，确保复制同步无误。
  • 故障转移脚本：你可以自定义故障转移脚本，以便根据特定需求进行调整，例如自动调整 DNS 或修改应用配置。
  • 监控：可以将 MHA 集成到系统的监控工具（如 Zabbix、Prometheus）中，以便实时监控 MySQL 的健康状态。

总结

配置 MHA 主要包括以下步骤：

  1. 配置 MySQL 主从复制。
  2. 安装和配置 MHA Manager 以监控 MySQL 集群并执行故障转移。
  3. 配置 SSH 无密码登录，以便 MHA Manager 能够与各个 MySQL 节点进行交互。
  4. 测试故障转移过程，确保 MHA 能够在主库宕机时自动切换。

通过这些步骤，你就可以实现 MySQL 的高可用性，保证在数据库故障时系统能够自动切换到新的主库。

avatar
文章
阅读
粉丝