《MySQL进阶（十一）：集群架构与实践专题（一）》
MySQL集群
- 核心定位：是高可用、高性能的数据库解决方案，用于满足大规模应用程序的数据访问需求。
- 解决的关键问题
- 性能提升：通过多服务器负载分散，提升数据库读写性能。
- 高可用性：借助数据冗余和故障转移机制，单个节点故障不影响整体服务。
- 扩展性：可通过添加节点水平扩展系统容量与处理能力。
- 数据一致性：利用复制和同步技术，确保多节点间数据一致。
- 读写分离：主从复制架构下，写操作集中在主库，读操作分散到从库，提升读性能。
- 分库分表：解决单一数据库性能瓶颈，需中间件 / 框架支持数据分布与路由。
- 负载均衡：将请求合理分配到不同节点，防止单个节点过载。
- 适用场景：适用于高可用、高性能、高并发的场景，如电信、在线游戏、电子商务、社交网络等领域。
单机模式
- 部署特点：采用少量服务器部署应用程序和数据库，数据库服务器仅一台，多个应用程序服务器（业务服务器）共同访问这一台数据库服务器。
- 局限性
- 性能瓶颈：所有数据都从单台数据库服务器获取，访问量增加时，数据库服务器访问压力剧增。
- 可用性风险：若数据库服务器出现网络、IO 或系统故障等异常，会导致整个业务系统无法正常工作。
- 扩展性不足：当应用访问量和数据量持续增长，单台数据库服务器将无法支撑业务系统，此时需将数据库部署为集群来解决这些问题。
集群模式
- 核心特点：多台数据库服务器共同承担整个系统的数据读写负载。
- 一主多从部署（以一主二从为例）
- 数据写入：仅向主服务器写入数据。
- 数据同步：从服务器通过数据同步机制，将主库新增数据复制到自身。
- 数据读取：所有查询操作都访问从服务器，实现读写操作分散到不同服务器，有效降低单台服务器压力，提升业务系统性能。
- 集群部署类型：有一主一从、一主多从、多主多从等多种类型，可根据业务场景选择，此处主要讲解一主多从的部署方式。
主从架构
在主从架构中分为两个⻆⾊，分别是主服务器(Master)和从服务器(Slave)
- 主服务器(Master)主要负责写操作和简单查询操作
- 从服务器(Slave)主要负责复杂查询操作和备份（从服务器和主服务器都保存完整的数据）
主从复制核心原理
主从复制的目的是保证从服务器与主服务器数据一致。其基本原理是：主服务器将数据操作（DML 和 DDL）记录到二进制日志（binlog）中，从服务器复制主服务器的 binlog，并将其中记录的操作转换为 SQL 语句，在从服务器上重放（重新执行），从而确保从服务器数据与主服务器数据的一致性。
主从复制流程（结合图示步骤）
- 建立连接：从服务器（Slave）与主服务器（Master）建立连接。
- 主服务器执行数据操作：主服务器执行 insert、update、delete 等 DML 操作以及 DDL 操作。
- 主服务器写入 binlog：主服务器将这些数据操作记录写入二进制日志（Binary Log）。
- 从服务器读取 binlog：从服务器的 I/O 线程（I/O thread）从主服务器的 binlog 中读取操作信息。
- 从服务器写入中继日志：从服务器将读取到的操作信息写入中继日志（Relay Log）。
- 从服务器 SQL 线程读取中继日志：从服务器的 SQL 线程（SQL thread）读取中继日志中的操作信息。
- 从服务器重放操作：SQL 线程将这些操作在从服务器的数据库中重新执行，从而保证从服务器数据与主服务器数据一致。
涉及线程说明
在整个主从复制过程中涉及三个关键线程：
- 主服务器的 Binlog Dump 线程：负责将主服务器的 binlog 内容发送给从服务器。
- 从服务器的 I/O 线程：负责从主服务器读取 binlog，并写入从服务器的中继日志。
- 从服务器的 SQL 线程：负责读取中继日志中的操作，并在从服务器数据库中执行，以实现数据同步。
中继日志的作用：
- 断点追溯：它像 “进度条” 一样，记录了复制的位置，无论主从哪端出现故障，重启后都能精准找到恢复点，避免数据混乱或重复执行。
- 异步解耦与灵活调度：既可以让从库 “边存边执行”（提升实时性），也可以 “先存后执行”（应对从库临时高负载，或实现延迟复制用于灾备）。
- 并行执行优化：高版本 MySQL 能基于中继日志的结构，实现多线程并行回放 SQL，大幅提升从库的复制效率，这也是单线程直接执行难以做到的。
3 大核心作用：
- 读写分离：主库写、从库读，缓解主库压力，提升并发。
- 数据备份 + 故障切换：从库存完整数据，主库故障可快速切换，避免数据丢失和业务中断。
- 业务隔离：从库承接备份、数据分析、测试等操作，不影响主库核心业务
高性能架构
MySQL⾼性能架构主要分为读写分离与数据库分⽚
一、读写分离
- 架构逻辑：属于主从架构的应用，写操作集中在主服务器，读操作分散到从服务器；从服务器通过数据同步机制从主服务器获取数据。
- 核心价值：将读写操作分流到不同服务器，减轻单台服务器的负载压力，提升数据库的读性能和整体吞吐量。
二、数据库分片
- 架构逻辑：将原本单库中保存的完整数据，拆分为多个数据库服务分别保存部分数据（分片），多个分片数据库共同组成完整的数据集。例如原本一个数据库包含
t_user、t_order、t_goods三张表，分片后可将不同表分别存储在不同的数据库服务中。 - 核心价值：解决单一数据库的性能瓶颈和存储容量限制，通过水平扩展多个数据库服务，提升系统的扩展性和处理大规模数据的能力。
- 主从复制：如你看到的图中逻辑，主和从都存储完整的数据，从节点的数据是主节点的 “副本”，目的是实现数据冗余、读写分离（主写从读）、故障切换等。
- 数据库分片：才是 “将完整数据拆分成多个部分，每个分片节点存储一部分数据，合起来才是完整数据集” 的架构，和主从复制的设计目标完全不同。
简单总结：主从是 “数据全量复制”，分片是 “数据拆分存储”，二者是独立的技术方案
实中主从复制和数据库分片经常一起使用
为什么要一起用？
- 主从复制的短板：只能解决 “读写压力”（主写从读）和 “故障备份”，但解决不了 “数据量超大” 的问题 —— 如果单库数据达到 TB 级，就算有从库，查询和存储压力依然会很高。
- 数据库分片的短板：只能解决 “数据量拆分”（分散存储压力），但每个分片本身没有冗余，一旦某个分片节点故障，会导致该分片的数据不可用。
- 二者结合：既通过 “分片” 拆分数据、降低单库压力，又通过 “主从复制” 给每个分片做副本，实现冗余备份和读写分离，兼顾性能和可靠性。
Docker常⽤命令
实践：主从复制
核心应用场景
| 场景 | 说明 |
|---|---|
| 数据备份和恢复 | 实现实时数据备份，主服务器故障时从服务器接管服务，保证数据一致与业务连续 |
| 读写分离 | 写操作由主服务器处理，读操作由从服务器处理，减轻主服务器压力，提升并发处理能力 |
| 负载均衡 | 利用主从节点完整数据，通过策略将负载分摊到多个节点，提升系统负载均衡能力 |
系统特性提升
- 可用性：主数据库故障时，从数据库立即接管，保障系统正常运行。
- 可靠性：数据复制到多个数据库，避免单点故障。
- 可扩展性：通过对等或分区复制，将大型数据库拆分多个小型数据库，提升系统扩展性。
核心逻辑总结
主从复制通过将数据存储在多个数据库服务器且保持数据一致，使多个数据库可同时对外提供服务，从而在数据安全、性能、系统稳定性等方面实现优化。
⼀主⼀从
⼀台主服务器主要负责读写操作，⼀台从服务器主要负责读操作或备份
⼀主多从
⼀台主服务器负责写操作，多台从服务器负责读操作和备份。从节点从主节点同步数据
⼀台主服务器负责写操作，多台从服务器负责读操作和备份。其中⼀个从节点从主节点同步数据， 并为其他从节点提供数据同步服务，这样可以降低主节点数据同步的压⼒
多主多从
以上的主从配置在实际中部署多套，避免单台故障
主从复制配置
架构图
以下⽰例中使⽤⼀主两从架构，当往主服务器中写⼊数据时，从服务器可以实现⾃动同步，查询时 可以在任⼀节点获取数
服务器规划
- 在单台服务器上使⽤ Docker 模拟多台服务器的场景
- 主从服务器IP⼀致，端⼝号不同
- 主服务器：容器名bit-mysql-master 端⼝号 53306
- 从服务器1：容器名bit-mysql-slave1 ，端⼝号 53307
- 从服务器2：容器名 bit-mysql-slave2 ，端⼝号 53308
- 注意：启动docker前先关闭防⽕墙