文日小栈

1. 完整回答

MySQL 集群部署主要是通过多个数据库实例协同工作，解决单机部署中的单点故障、读性能瓶颈和服务可用性问题。

常见方案有主从复制、主从复制配合高可用组件，以及官方的 InnoDB Cluster。生产环境中，如果需要自动故障切换，可以采用 InnoDB Cluster，也就是 MGR 组复制、MySQL Shell 和 MySQL Router 的组合。

典型架构是三个 MySQL 节点，采用单主模式，一个主节点负责读写，两个从节点负责数据复制和读取。

底层通过 MGR 的组通信、事务认证和多数派机制维护集群状态。正常情况下，写请求进入主节点，事务经过组内协调后提交，其他节点再应用相同的数据变更。如果主节点故障，剩余节点在满足多数派的情况下自动选举新主节点，MySQL Router 将后续连接路由过去。

实际部署时，先准备三个独立节点，完成 MySQL 配置，再通过 MySQL Shell 创建集群、加入节点，最后配置 Router 和业务连接。

这套方案适合对高可用要求较高的业务系统。但集群部署仍然需要处理复制延迟、故障期间的连接中断，以及备份恢复问题。另外，单主模式的写入能力仍然受单个主节点限制。

2. 核心原理与关键概念

2.1 集群整体架构

以三节点 InnoDB Cluster 为例：

                业务应用
                   |
              MySQL Router
                   |
          +--------+--------+
          |                 |
       读写连接           只读连接
          |                 |
      MySQL A           MySQL B / C
       Primary          Secondary
          |                 |
          +------ MGR ------+
             组复制与故障检测

三个数据库实例通过 MGR 组成复制组。单主模式下，主节点处理写请求，从节点可以承担读取请求。

MySQL Router 提供统一的连接入口，并根据集群拓扑将连接分配给合适的节点。

2.2 核心组件

组件	核心作用
MySQL Server	存储数据、执行 SQL、管理事务
MGR（Group Replication）	负责组内通信、事务认证、故障检测和主节点选举
MySQL Shell	通过 AdminAPI 创建、管理和维护集群
MySQL Router	根据节点角色和集群状态进行连接路由，支持相应的读写分流配置
GTID	为事务提供全局唯一标识，方便复制定位、数据恢复和故障切换

2.3 MGR 的事务同步流程

主节点执行事务 → 广播事务变更和写集合 → 组内确定事务顺序 → 事务认证 → 主节点提交 → 其他节点应用事务

关键环节有三个：

组通信：通过基于 Paxos 的通信机制协调成员状态和事务顺序。
事务认证：利用写集合检测冲突，保证组内成员按照一致的结果处理事务。
数据应用：事务通过认证后，各节点应用相应变更。从节点应用可能滞后，因此不同节点上的数据可见时间可能存在差异。

2.4 实际部署流程

环境准备 → 实例配置 → 创建集群 → 加入节点 → 配置路由 → 故障演练 → 监控备份

步骤	主要操作
1. 环境准备	准备三台独立服务器，统一兼容的 MySQL 版本，配置网络、DNS 和时间同步
2. 实例配置	使用 InnoDB 存储引擎，确保表具备主键或等价非空唯一键，并配置集群账号、GTID、日志和组通信
3. 创建集群	通过 `dba.configureInstance()` 检查和配置实例，使用 `dba.createCluster()` 创建集群
4. 加入节点	使用 `cluster.addInstance()` 加入另外两个节点，通过克隆或增量恢复同步数据
5. 配置路由	使用 `mysqlrouter --bootstrap` 初始化 Router，配置应用连接入口
6. 验证集群	通过 `cluster.status()` 检查角色和状态，模拟主节点故障并验证自动选主
7. 运维保障	配置监控告警、数据备份、Binlog 保留策略和恢复演练

生产部署需要将配置持久化，避免实例重启后无法正常加入集群。同时，应把三个节点放在不同故障域，避免单台物理机或单个故障域失效导致整个集群不可用。

3. 高频面试追问

3.1 MySQL 常见的集群部署方案有哪些？如何选择？

常见方案主要有三类：

第一类是主从复制，通常采用一主多从，通过 Binlog 同步数据，配合读写分离提高读取能力。部署简单、成本较低，但主库故障时需要额外的切换机制。

第二类是主从复制加高可用组件，例如 Orchestrator，通过检测主库状态、选择新主库、调整复制关系，实现自动故障切换。适合已经使用传统主从架构的系统。

第三类是 InnoDB Cluster，基于 MGR 实现组复制、自动选主和故障恢复，配合 MySQL Router 提供统一入口。

如果业务以读多写少为主，而且能够接受一定复制延迟，传统主从架构通常就能满足需求。如果对自动故障切换和集群一致性要求较高，可以优先考虑 InnoDB Cluster。

3.2 MySQL 主从复制的底层流程是什么？

MySQL 主从复制主要依赖 Binlog 和 Relay Log，基本流程是：

主库提交事务并记录 Binlog → 从库接收日志 → 写入 Relay Log → 从库重放事务 → 完成数据同步。

主库通过 Binlog 记录数据变更，从库的接收线程获取这些日志并写入本地中继日志，再由应用线程执行相应变更。为了提高复制效率，从库也可以使用并行应用线程。

通常还会启用 GTID。每个事务都有唯一标识，从库可以根据已执行的 GTID 集合定位需要同步的事务，简化主从切换和故障恢复。

普通异步复制中，主库提交成功后，无须等待从库接收或执行完成，因此可能出现复制延迟和故障丢失数据的问题。

3.3 为什么 MGR 通常部署三个节点？两个节点可以吗？

三个节点是兼顾成本与单节点故障容忍能力的常见选择。

MGR 基于多数派机制协调事务和成员状态。只有超过半数的节点能够正常通信，集群才能继续推进需要组内协调的操作。

例如三个节点中，任意一个节点故障，剩余两个节点仍然构成多数派，可以继续提供服务。

如果只有两个节点，其中一个故障后，剩余一个节点无法形成多数派，集群就会失去正常推进事务的能力。

因此，三节点可以容忍一个节点故障，五节点可以容忍两个节点故障。节点越多，资源和组通信开销也会增加，需要根据可用性目标选择规模。

3.4 MGR 集群中主节点宕机后，会发生什么？

在三节点单主集群中，假设 A 是主节点，B、C 是从节点。

故障切换主要经过以下流程：

检测 A 失联 → B、C 达成成员变更共识 → 选举新主节点 → 新主节点恢复可写状态 → Router 将新连接路由到新主节点。

MGR 通过组通信检测故障，并在多数派仍然存在的情况下完成成员变更和主节点选举。

如果新主节点还有尚未应用的事务，可以通过故障切换一致性配置，要求它先完成积压事务的应用，再处理新的业务请求。

需要注意，自动选主不代表业务请求完全无感知。原有连接可能中断，正在执行的事务也可能失败。

继续追问：业务系统如何处理故障期间的事务？

业务层需要具备连接重建、超时处理和有限次数重试能力。对于提交结果不明确的事务，要先确认执行结果，或者通过业务唯一编号、幂等约束等方式避免重复写入。

例如订单创建请求在提交时断开连接，数据库可能已经提交成功，直接重复创建就有风险，因此需要利用唯一订单号保证幂等性。

3.5 MGR 是如何保证数据一致性的？是否属于强一致？

MGR 通过组内事务排序和冲突认证，保证各成员采用一致的事务处理结果，但默认情况下仍可能读到尚未同步完成的数据。

写事务在提交阶段，需要通过组通信确定顺序，并利用写集合进行冲突检测。

如果两个不同节点的并发事务修改同一行数据，在多主模式下可能发生认证冲突，其中一个事务需要回滚。

另外，事务通过认证并在主节点提交后，其他节点可能还没有完成应用，因此从节点存在短暂的数据可见性延迟。

MySQL 提供 group_replication_consistency 参数控制一致性级别，例如：

EVENTUAL：允许从节点应用滞后，优先考虑性能。
BEFORE：事务执行前等待之前的事务应用完成。
AFTER：写事务等待其他在线成员完成相应变更的应用。
BEFORE_ON_PRIMARY_FAILOVER：新主节点先处理完积压事务，再接受新的业务请求。

一致性保证越强，通常需要付出的等待成本也越高。

3.6 MySQL Router 如何实现故障切换和读写分离？

MySQL Router 根据集群元数据和节点角色，把业务连接路由到合适的数据库实例。

对于 InnoDB Cluster，Router 可以通过集群元数据识别当前主节点和从节点。当主节点发生切换后，Router 会更新拓扑信息，将后续连接发送到新的可用节点。

常见的连接端口包括：

6446：读写连接，通常路由到主节点。
6447：只读连接，通常路由到从节点。
6450：MySQL Router 8.4 支持的自动读写分离连接端口，具体以部署配置为准。

其中，自动读写分离功能可以根据 SQL 或事务类型选择读写节点，使用时需要满足对应的 Router 配置要求。

Router 解决了客户端如何找到正确数据库节点的问题，但发生故障时，已有连接仍可能断开，业务端需要进行异常处理和重新连接。

3.7 集群出现主从复制延迟，应该怎么处理？

首先定位复制延迟发生在哪个环节，再根据业务对数据实时性的要求选择处理方案。

常见原因包括主库写入量过大、网络传输缓慢、从库磁盘性能不足，以及大事务或慢 SQL 导致日志应用积压。

处理时可以先检查复制线程、事务应用队列、节点资源使用率和复制延迟情况。

对于传统主从复制，可以优化慢 SQL、拆分大事务、使用并行复制，并检查磁盘和网络瓶颈。

如果是读写分离产生的一致性问题，可以让关键读取访问主节点，或者通过 GTID 等待目标从库追上指定事务。

对于 MGR，还可以根据业务要求调整事务一致性级别，并监控流控状态。

继续追问：为什么刚写入订单，马上查询却查不到？

通常是写请求已经在主库提交，但对应事务还没有在从库应用完成。

如果订单创建后必须立即查询最新状态，可以将该请求的后续读取路由到主库。对于允许短暂延迟的查询，例如商品列表或历史记录，则可以继续访问从库。

3.8 MGR 单主模式和多主模式应该如何选择？

大部分常规业务更适合单主模式，多主模式适合能够控制写冲突的特殊场景。

单主模式只有一个节点接受业务写入，其他节点负责复制和读取。写入路径比较明确，事务冲突更容易控制，应用侧也更简单。

多主模式允许多个节点同时接收写请求，但不同节点上的事务可能修改相同的数据，导致认证冲突和事务回滚。

例如两个节点同时修改同一条库存记录，就可能发生冲突，业务需要处理失败和重试。

多主模式还存在部分事务和数据库功能的使用限制。即使启用多主，也无法简单地把数据库写入吞吐量理解为节点数量乘以单机吞吐量。

因此，普通订单、账户、库存等事务型业务，通常优先选择单主模式。

3.9 集群节点故障后如何重新加入？如果失去多数派怎么办？

单节点故障和集群失去多数派，需要采用不同的恢复方式。

如果只是单个节点退出，而集群仍然正常运行，可以先排查故障原因，再通过 cluster.rejoinInstance() 尝试重新加入。

重新加入时，需要恢复该节点缺少的数据。可以使用增量恢复，也可以通过 MySQL Clone 复制健康节点的数据快照。

如果集群失去多数派，剩余节点无法继续正常处理需要多数派确认的事务。此时需要先确认其他节点状态，排除仍在运行的独立集群或网络分区，再按恢复流程处理。

如果整个集群全部停止，可以检查各节点的事务状态，选择合适的恢复节点，并通过 dba.rebootClusterFromCompleteOutage() 执行恢复。

不能随意强制选主或同时初始化多个复制组，否则可能造成脑裂或数据分叉。

3.10 MySQL 集群上线后，如何保证稳定性和数据安全？

生产环境主要从监控、故障演练、数据持久化和备份恢复四个方面保障。

首先，监控集群成员状态、主节点角色、复制延迟、事务应用队列、磁盘空间、连接数以及 Router 的可用性。

其次，进行故障演练，例如停止主节点、模拟网络中断、重启从节点，验证自动选主、连接恢复和数据一致性。

数据持久化方面，需要根据可靠性要求配置 innodb_flush_log_at_trx_commit 和 sync_binlog 等参数。

备份方面，要定期进行全量备份，保留相应的 Binlog，并通过恢复演练验证备份有效性。

另外，需要明确两个指标：RPO 表示最多允许丢失多少数据，RTO 表示故障后允许多长时间恢复服务。

集群提供节点冗余，但误删除、错误更新等操作也可能复制到其他节点。因此，多副本部署仍然必须配合独立备份。

4. 易混淆概念对比

4.1 主从复制与 InnoDB Cluster

对比维度	传统主从复制	InnoDB Cluster
底层机制	基于 Binlog 复制	基于 MGR 组复制
数据同步	通常采用异步复制	组内协调事务顺序和认证
自动选主	需要额外高可用组件	内置自动主节点选举
故障容忍	取决于切换方案	依赖多数派
适用场景	读扩展、简单主从架构	高可用、自动故障切换

4.2 异步复制、半同步复制与 MGR

复制方式	核心机制	主要特点
异步复制	主库提交后，无须等待从库确认	延迟较低，但故障时可能丢失尚未复制的事务
半同步复制	主库等待规定数量的从库确认收到日志	降低数据丢失风险，但确认收到不代表已应用；超时可能降级为异步
MGR	组通信确定事务顺序，并进行冲突认证	支持自动选主和多数派容错，从节点应用仍可能滞后

4.3 MGR 与 InnoDB Cluster

概念	区别
MGR	MySQL 的组复制技术，负责事务复制、成员管理、选主和故障容忍
InnoDB Cluster	基于 MGR，结合 MySQL Shell 和 MySQL Router 形成的集群管理与高可用方案

MGR 是核心复制机制，InnoDB Cluster 则提供更完整的部署、管理和连接路由能力。

4.4 单主模式与多主模式

对比维度	单主模式	多主模式
写入节点	一个	多个
读请求	主节点和从节点	多个主节点
写冲突	更容易控制	可能产生分布式写冲突
实现复杂度	较低	较高
常见场景	常规事务型业务	低冲突、多写入入口场景

4.5 InnoDB Cluster 与 NDB Cluster

对比维度	InnoDB Cluster	NDB Cluster
存储引擎	InnoDB	NDB
核心架构	多个 MySQL 实例通过组复制协作	管理节点、数据节点和 SQL 节点协作
数据组织	各组成员维护完整数据副本	数据分片存储，并通过副本提供冗余
主要目标	常规 MySQL 数据库高可用	分布式数据存储与高可用
典型场景	业务系统、事务型应用	对分布式存储和高可用有特定要求的系统

4.6 高可用、读写分离与分库分表

概念	主要解决的问题	典型方式
高可用	节点故障导致服务不可用	多副本、故障检测、自动切换
读写分离	单节点读取压力过大	主节点写入、从节点读取
分库分表	单库数据量或写入能力达到瓶颈	按业务规则拆分数据
备份恢复	误操作、数据损坏及灾难后的数据恢复	全量备份、Binlog、时间点恢复

这几种方案解决的问题不同，可以根据业务需求组合使用。特别是单主 InnoDB Cluster，虽然具备高可用和读扩展能力，但写入仍然集中在一个主节点，无法直接替代分库分表。

5. 总结

MySQL 集群部署主要用于提高数据库的可用性、容错能力和读取性能。常见方案包括主从复制和 InnoDB Cluster，其中 InnoDB Cluster 通过 MGR 完成事务协调、数据复制和自动选主，再通过 MySQL Router 提供统一连接入口。典型部署采用三节点单主架构，依赖多数派机制容忍单节点故障。需要注意，组复制仍可能存在数据应用延迟，故障切换也可能导致连接中断，而且单主架构的写入能力受到主节点限制。因此，生产环境除了部署集群，还需要配合连接重试、监控告警、故障演练和独立备份，才能形成相对完整的数据库高可用方案。