MariaDB Galera 原理及用例说明-EW帮帮网

一、底层原理

MariaDB Galera 集群是一种基于同步多主架构的高可用数据库解决方案，适合需要高并发、低延迟和数据强一致性的场景。以下是部署和配置 MariaDB Galera 集群的简明步骤：

1. 环境准备

节点要求：至少 3 个节点（奇数节点避免脑裂），确保网络互通。
系统环境：所有节点使用相同操作系统（如 CentOS 7/8、Ubuntu 20.04+）。

依赖安装：

bash

复制

# CentOS
sudo yum install -y mariadb-server galera

# Ubuntu
sudo apt-get install -y mariadb-server galera

2. 配置 MariaDB Galera 集群

修改配置文件 (`/etc/my.cnf.d/server.cnf` 或 `/etc/mysql/mariadb.conf.d/60-galera.cnf`)

ini

复制

[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so

# 集群名称（所有节点一致）
wsrep_cluster_name = "my_galera_cluster"

# 当前节点IP和其他节点IP列表（以逗号分隔）
wsrep_cluster_address = "gcomm://node1_ip,node2_ip,node3_ip"

# 当前节点名称（唯一）
wsrep_node_name = "node1"

# 当前节点地址
wsrep_node_address = "node1_ip"

# 同步方法（推荐使用 mariabackup）
wsrep_sst_method = mariabackup

# SST 认证信息（所有节点一致）
wsrep_sst_auth = "sst_user:sst_password"

# InnoDB 配置（调整缓冲池大小）
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M

创建 SST 用户（在每个节点的 MariaDB 中执行）

sql

复制

CREATE USER 'sst_user'@'localhost' IDENTIFIED BY 'sst_password';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sst_user'@'localhost';

3. 启动集群

首次启动第一个节点（引导集群）：

bash

复制

sudo systemctl stop mariadb
sudo galera_new_cluster
sudo systemctl start mariadb

启动其他节点：

bash

复制
```
sudo systemctl restart mariadb
```

4. 验证集群状态

检查集群节点数：

sql

复制
```
SHOW STATUS LIKE 'wsrep_cluster_size';
```
输出应为 3（假设有 3 个节点）。
检查集群健康状态：

sql

复制
```
SHOW STATUS LIKE 'wsrep_%';
```
关键指标：
- wsrep_ready: ON（节点可读写）
- wsrep_connected: ON（节点已连接）
- wsrep_cluster_status: Primary（正常状态）

5. 常见操作

添加新节点

在新节点上配置相同的 /etc/my.cnf。
直接启动 MariaDB：

bash

复制
```
sudo systemctl start mariadb
```

安全关闭集群

关闭最后一个节点：

bash

复制
```
sudo systemctl stop mariadb
```

6. 故障排查

日志位置：/var/log/mysql/error.log 或 /var/log/mariadb/mariadb.log
常见问题：
- 节点无法加入集群：检查防火墙是否开放端口（3306, 4567, 4568, 4444）。
- SST 失败：确认 wsrep_sst_auth 的用户名密码正确。
- 脑裂问题：强制重启少数节点并重新加入集群。

7. 优化建议

网络：确保节点间低延迟（建议内网专用网络）。
负载均衡：使用 HAProxy 或 ProxySQL 分发读请求。
监控：集成 Prometheus + Grafana 监控 wsrep 指标。

如有具体问题（如错误日志内容），可提供详细信息进一步分析！

底层原理

已深度思考（用时 24 秒）

嗯，用户之前问了关于MariaDB Galera集群的部署步骤，现在他们又询问“底层原理”。这说明用户已经完成了初步的配置，现在想更深入地了解集群是如何工作的。作为新手，用户可能在使用过程中遇到了一些问题，或者想优化集群性能，因此需要理解背后的机制。

首先，用户可能想知道Galera集群和传统的主从复制有什么不同。传统的主从是异步的，而Galera是同步多主，这对数据一致性很重要。用户可能关心数据如何同步，以及为什么Galera能保证强一致性。

接下来，用户可能对Galera的核心组件感兴趣，比如wsrep API、组通信（gcomm）和认证器。他们可能听说过这些术语，但不清楚具体作用。需要解释每个部分的功能，以及它们如何协作实现数据同步。

另外，关于事务的流程，用户可能想知道一个事务在提交时如何在集群中传播，确认机制是怎样的。这里需要详细说明事务的认证和应用过程，以及为什么需要多数节点确认。

SST和IST的区别也是关键点。用户可能在扩容或恢复节点时遇到过全量同步和增量同步的问题，需要解释这两种同步方式的适用场景和原理。

脑裂问题可能让用户头疼，特别是在网络分区时。用户想知道Galera如何通过Quorum和权重配置来避免脑裂，以及出现问题时如何恢复。

高可用性和数据一致性之间的平衡也是用户关心的。Galera的同步复制虽然保证了强一致性，但可能影响性能，用户需要了解背后的机制和可能的优化方法。

最后，用户可能想了解Galera的局限，比如对DDL操作的支持、写扩展问题以及网络延迟的影响。这些信息能帮助他们合理设计架构，避免潜在问题。

在回答时，需要保持逻辑清晰，用简单的类比帮助理解，比如将认证过程比作议会投票，或者用快递包裹来解释事务传输。同时，结合用户之前的部署步骤，指出原理部分如何影响实际配置和故障处理，比如wsrep_cluster_address的配置或SST用户设置。

总结来说，用户需要的是从基础概念到工作机制的全面解析，帮助他们不仅知道如何配置，还能理解为什么这样配置，以及如何应对可能出现的问题。这有助于他们更好地维护和优化Galera集群，提升系统的稳定性和性能。

MariaDB Galera 集群的底层原理基于 同步多主复制（Synchronous Multi-Master Replication），通过 Galera Library 实现数据一致性、高可用性和分布式事务处理。以下是其核心原理的深入解析：

1. 核心组件与架构

(1) WriteSet Replication (wsrep) API**

作用：Galera 基于 wsrep API 实现节点间数据同步，该 API 定义了事务在节点间的复制接口。
关键行为：
- 将事务的二进制变更（WriteSet）广播到所有节点。
- 确保事务在所有节点上按相同顺序提交（Total Ordering）。

(2) 组通信系统（Group Communication System, gcomm）

功能：实现节点间的消息传递和成员管理（如节点加入/退出检测）。
协议：基于 Paxos 变种（如 gcomm 协议），确保消息的可靠传输和一致性。
端口：默认使用 4567（集群通信）、4568（增量状态传输）、4444（全量状态传输）。

(3) 认证器（Certifier）

作用：验证事务是否与其他事务冲突（如主键冲突、锁冲突）。
过程：每个节点独立验证事务，通过后标记为“可提交”。

2. 事务处理流程

当一个事务在任意节点提交时，Galera 集群会按以下步骤处理：

本地事务提交：
- 事务在本地节点执行，生成 WriteSet（包含事务的二进制变更和元数据）。
- 事务进入本地节点的 prepare 阶段，但尚未提交。
广播 WriteSet：
- 本地节点通过 gcomm 将 WriteSet 广播到集群所有节点。
全局认证（Certification）：
- 所有节点对接收到的 WriteSet 进行冲突检测：
  - 检查事务是否与其他事务的 WriteSet 冲突（如修改同一行数据）。
  - 若无冲突，事务被标记为全局有效（Certified）。
按序提交（Total Order Commit）：
- 所有节点按 相同的顺序 提交事务，保证数据一致性。
- 事务最终在所有节点上提交（同步提交）。
确认（ACK）：
- 发起事务的节点收到多数节点的确认（Quorum）后，向客户端返回成功。

3. 同步复制的关键机制

(1) 全局事务序列（Global Transaction Sequence）

所有事务被赋予一个全局唯一的序列号（GTID），确保事务在集群中按统一顺序提交。

(2) 冲突检测（Certification-Based Conflict Resolution）

乐观锁机制：假设事务冲突概率低，先执行后验证。
若检测到冲突（如两个节点同时修改同一行），Galera 会回滚其中一个事务（由客户端重试）。

(3) 状态传输（State Snapshot Transfer, SST & IST）

SST（全量同步）：新节点加入时，从现有节点拉取完整数据快照（如使用 mariabackup）。
IST（增量同步）：节点短暂离线后，仅同步缺失的事务（通过 GTID 追踪）。

4. 避免脑裂（Split-Brain）

Galera 通过 Quorum 机制 和 权重配置 防止网络分区导致的脑裂：

Quorum 要求：集群需多数节点存活（如 3 节点集群至少 2 节点在线）。
自动隔离（Non-Primary 状态）：
- 若节点失去 Quorum，会拒绝写入操作（防止数据分歧）。
- 需人工介入修复网络或重新同步。

5. 高可用性与一致性保证

(1) 强一致性（Strong Consistency）

所有节点数据视图一致（CAP 理论中的 CP 模型）。
客户端无论连接到哪个节点，都能读取最新数据。

(2) 多主写入（Multi-Master）

任何节点均可处理读写请求，无单点故障。
通过全局锁（如 wsrep_causal_reads）避免读未提交数据。

(3) 自动故障转移

节点故障时，集群自动剔除故障节点，客户端可重连到其他节点。

6. 性能优化与限制

优点：

低延迟：事务在本地提交后立即返回，后台异步广播 WriteSet。
线性扩展：读性能随节点数增加线性提升。

限制：

写扩展性：所有节点需处理所有写操作，写性能受限于最慢节点。
DDL 操作限制：某些 DDL（如 ALTER TABLE）需要特殊处理（建议使用 TOI 或 RSU 模式）。
网络依赖：高网络延迟可能导致事务提交变慢。

7. 与异步复制的本质区别

特性	Galera 同步复制	传统异步复制
数据一致性	强一致性（所有节点同步提交）	最终一致性（主从延迟）
故障恢复	自动切换，无数据丢失	可能丢失未同步的数据
性能影响	事务延迟受网络影响	主节点无复制延迟影响
适用场景	高可用、强一致性场景	读写分离、灾备场景

8. 底层原理的实际应用

配置调优：
- 调整 innodb_flush_log_at_trx_commit=2 提升性能（牺牲部分持久性）。
- 设置 wsrep_slave_threads 匹配 CPU 核心数。
监控指标：
- wsrep_local_state：节点状态（4 表示正常同步）。
- wsrep_flow_control_paused：流量控制暂停时间（>0 表示复制压力大）。

总结

MariaDB Galera 的底层原理通过 全局事务序列化、冲突检测和同步提交 实现多主强一致性，核心是牺牲部分写性能换取高可用和数据一致性。理解这些机制有助于合理设计集群架构（如控制节点数量、优化网络）和故障排查（如脑裂恢复、SST/IST 问题）。

二、用例说明执行流程

在 MariaDB Galera 集群中，一个多语句更新事务的完整执行过程涉及 本地事务执行、全局冲突检测、同步提交 等多个阶段。以下是其详细流程：

1. 事务启动阶段

客户端连接任意节点（如 Node1），执行以下多语句事务：

sql

复制

START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
COMMIT;

2. 本地事务执行

(1) 本地节点（Node1）执行事务

步骤：
1. 本地节点解析 SQL，在内存中执行事务逻辑。
2. 生成 WriteSet：记录事务的二进制变更（如 InnoDB 的 redo log）。
3. 事务进入 PREPARE 阶段（未提交到本地数据库）。

(2) WriteSet 结构

包含：
- 全局事务 ID（GTID）：唯一标识事务。
- 变更数据：二进制格式的行级修改。
- 依赖关系：事务的顺序依赖（由全局序列号保证）。

3. 全局冲突检测（Certification）

(1) 广播 WriteSet 到集群

Node1 通过组通信层（gcomm）将 WriteSet 广播到所有节点（Node2, Node3）。

(2) 各节点独立验证冲突

冲突检测逻辑：
- 检查事务修改的行是否被其他未提交事务锁定。
- 验证主键冲突、外键约束等。
认证结果：
- 若无冲突，标记事务为 Certified（可提交）。
- 若冲突（如 Node2 已提交一个修改同一行的其他事务），标记事务为 Aborted（需回滚）。

4. 全局有序提交

(1) 确定事务提交顺序

所有节点通过 全局事务序列（GTID） 商定事务提交顺序。
事务按 相同的全局顺序 提交到所有节点。

(2) 同步提交事务

所有节点按序提交：
- 各节点将 WriteSet 应用到本地数据库（无需重新执行 SQL，直接应用二进制变更）。
- 提交后的数据在所有节点上完全一致。

(3) 客户端确认

Node1 收到多数节点（Quorum）的提交确认后，向客户端返回 COMMIT 成功。

5. 异常处理与回滚

(1) 冲突回滚

若任意节点检测到冲突，发起事务的节点（Node1）会收到 Certification Failure。
自动回滚：事务在 Node1 本地回滚，客户端收到错误（需重试事务）。

(2) 网络故障

部分节点离线：
- 若 Quorum 存在（多数节点在线），事务在存活节点提交，离线节点恢复后通过 IST/SST 同步。
- 若 Quorum 丢失，存活节点进入 Non-Primary 状态，拒绝写入。

6. 关键特性与流程对比

(1) 与传统单机 MySQL 的差异

阶段	Galera 集群	单机 MySQL
事务提交	同步提交到所有节点	仅本地提交
冲突解决	全局认证阶段检测冲突	依赖行锁或 MVCC
性能影响	延迟取决于最慢节点的响应	仅本地磁盘/内存速度

(2) 多语句事务的原子性保证

全有或全无：所有语句的变更要么全部提交到所有节点，要么全部回滚。
全局锁协调：事务涉及的锁信息通过 WriteSet 传递，确保全局一致性。

7. 监控与日志

(1) 关键监控指标

SHOW STATUS LIKE 'wsrep_%';：
- wsrep_local_state_comment：节点状态（Synced/Donor/Joiner）。
- wsrep_last_committed：最后提交的 GTID。
- wsrep_cert_deps_distance：事务依赖的间隔（反映冲突频率）。

(2) 日志分析

错误日志（/var/log/mariadb/mariadb.log）：
- 查找 Certification failed 或 WSREP: Transaction cancelled。

Galera 调试日志：

ini

复制

[galera]
wsrep_debug = ON    # 启用详细日志

8. 性能优化建议

减少冲突：
- 设计事务时避免热点行（如批量更新改为分散操作）。
- 使用乐观锁机制（如版本号字段）。
调整参数：
- 增加 wsrep_slave_threads 提升并发应用 WriteSet 的能力。
- 优化 innodb_flush_log_at_trx_commit = 2（牺牲部分持久性换取性能）。
网络优化：
- 使用低延迟、高带宽的专用网络。
- 启用 TCP 快速打开（tcp_fastopen）。

总结

MariaDB Galera 集群中，多语句更新事务的完整执行流程通过 本地执行、全局认证、有序提交 实现强一致性。其核心是通过牺牲部分写延迟（等待多数节点确认）换取多主架构下的数据一致性。理解这一流程有助于：

设计低冲突的分布式事务逻辑。
快速定位事务失败原因（如认证冲突、网络分区）。
合理优化集群参数与架构（如控制事务粒度、提升网络性能）。

三、常见问题

每个pod节点队列容量设置过少，导致频繁限流，从流控dashboard能够看到限流时机，增大队列容量。
队列容量加大，就会有db延迟，导致多节点数据无法强一致，在发生宕机故障时候，有部分不一致数据丢失风险。

MariaDB Galera 原理及用例说明