Jepsen测试发现MariaDB Galera Cluster 12.1.2存在事务丢失问题：在推荐配置下节点连续崩溃时会丢失已提交事务，且在进程崩溃和网络分区时也会丢失事务。即使无故障，该集群仍会出现丢失更新和脏读现象，无法达到其宣称的"介于可序列化和可重复读之间"的隔离级别。该研究由Jepsen独立完成。

Jepsen对MariaDB Galera Cluster 12.1.2的测试分析

核心发现

1. 事务丢失问题

   • 配置缺陷：在推荐的innodb_flush_log_at_trx_commit=0设置下，当多个节点连续崩溃时，已提交事务会丢失（MDEV-38974）。
   • 极端故障场景：即使设置为1，进程崩溃和网络分区仍可能导致少量已提交事务丢失（MDEV-38976）。

2. 隔离级别不达标

   • 丢失更新（Lost Update）：健康集群中频繁出现P4异常（违反快照隔离和可重复读），例如事务B的更新被事务A覆盖（MDEV-38977）。
   • 过时读（Stale Read）：已提交事务的写入可能对后续事务不可见（MDEV-38999）。

3. 文档误导性声明

   • MariaDB声称Galera提供"无事务丢失"和"即时全节点复制"，实际仅需法定节点在线即可提交，与文档描述的"全节点提交"矛盾。

测试方法

• 环境：3节点集群，Debian Trixie系统，模拟网络分区、进程崩溃等故障。
• 工具：使用Elle的列表追加检查器，通过事务依赖图分析隔离性异常。
• 用例设计：多表主键操作，检测写-写、写-读、读-写依赖。

建议与结论

• 用户措施：
  • 必须设置innodb_flush_log_at_trx_commit=1以降低数据丢失风险。
  • 避免依赖读-改-写模式（如ORM常见操作），因其在Lost Update下不安全。
• 厂商改进：
  • 修正文档中关于一致性的不准确描述。
  • 明确说明实际支持的隔离级别（当前弱于"读未提交"）。

局限性

本次测试未覆盖谓词操作、时钟偏差等场景，且仅能证伪不能证明无缺陷。

（注：原文中的历史背景、技术细节引用及未来工作建议等辅助内容已精简，完整分析可参考原始报告。）

总结评论内容：

1. 标题建议

• 认为当前标题不够准确，建议改为"Data loss cases with MariaDB Glaera Cluster 12.1.2"
• 引用："this really should be something like 'Data loss cases with MariaDB Glaera Cluster 12.1.2'"

2. Galera集群的正面评价

• 作者长期在低容量集群中使用Galera，认为其是可靠的多主解决方案
• 引用："I've been using it for over a decade...it's been a real workhorse"（"我使用它超过十年...它一直是可靠的主力"）

3. 对数据一致性问题的担忧

• 指出即使在健康集群中也存在陈旧读取和更新丢失等基本问题
• 引用："exhibits Stale Read, Lost Update...in healthy clusters"（"在健康集群中表现出陈旧读取、更新丢失..."）
• 认为这是MySQL作为分布式数据库的固有缺陷
• 引用："MySQL hasn't been designed to be a distributed database from the beginning"（"MySQL从一开始就不是为分布式数据库设计的"）

4. 对测试和文档的批评

• 质疑为何不采用Jepsen等专业测试工具
• 引用："why...don't you at least try using eg. aphyrs jepsen library"（"为什么不至少尝试使用Jepsen这样的库"）
• 批评文档更像广告而非技术说明
• 引用："Documentation looks more like advertisement"（"文档看起来更像广告"）

5. 实际部署中的问题

• 健康集群中的陈旧读取问题特别令人担忧
• 引用："The 'healthy cluster' aspect that makes this scary"（"正是'健康集群'这一点让人害怕"）
• 指出典型的负载均衡场景下会出现数据不一致
• 引用："we create a user on node A...the user doesn't exist yet"（"我们在节点A创建用户...但用户还不存在"）