10 混沌工程导论

 https://www.bilibili.com/video/BV1MQ4y1u7Bt?spm_id_from=333.788.videopod.episodes&vd_source=98f3349ab95218044e2c42b526a191ca&p=5

 

 

 

 

 

 

MySQL Replication（主从复制）是数据库高可用架构的基石。在分布式核心系统中，主库（Master）负责处理所有的写操作，并通过二进制日志（Binlog）将这些变更顺序记录下来；从库（Slave/Secondary）则作为数据副本，通过拉取并回放这些日志来保持与主库的数据最终一致性。

在微服务架构中，主从复制的核心作用是读写分离。业务服务通常会将写请求路由到主库，而读请求则分发到从库。这种模式极大地提升了系统的并发处理能力，但同时也埋下了隐患：一旦从库出现故障（如复制延迟过大或节点宕机），大量的读流量就会被强制转移到主库，导致主库负载激增，进而可能引发整个数据库集群的雪崩。

结合之前探讨的混沌工程实践，主从复制架构面临的具体挑战主要体现在以下几个方面：

1. 核心故障点与数据一致性风险

在主从复制架构中，最典型且危险的故障是主从延迟（Replication Lag）。

• 成因：从库通常是单线程（或有限线程）回放主库的 Binlog。如果主库执行了一条大事务（如批量更新百万级数据），或者遭遇了高并发写入，从库的 I/O 线程或 SQL 线程可能会跟不上主库的节奏。

• 后果：此时如果有读请求被路由到了从库，读取到的将是“过期”的数据（Stale Data）。在金融或电商场景中，这可能导致用户看到了未成功的订单状态，引发资损或严重的客诉。

2. 针对主从复制的混沌实验设计

为了验证系统在数据库层面的韧性，可以利用 ChaosBlade 等工具针对上述风险点设计以下实验：

• 实验一：模拟从库宕机（节点失效）

  • 操作：使用 blade destroy 或直接停止从库的 MySQL 进程。

  • 验证目标：观察中间件（如 ShardingSphere-Proxy 或 MyCat）或应用侧的负载均衡策略是否能迅速感知，并将读流量自动剔除该节点，全部转移到其他健康的从库上，同时确认主库不会因为流量突增而被压垮。

• 实验二：模拟主从网络延迟（网络分区）

  • 操作：参考之前的网络丢包实验，在 Master 和 Slave 之间的网络链路上注入高丢包率或延迟。

  • 验证目标：观察从库的 Seconds_Behind_Master 指标是否开始飙升。同时，验证应用的熔断机制是否生效——当检测到某个从库延迟过高时，自动将其标记为不可用，禁止向其发送读请求。

• 实验三：大事务导致的级联阻塞

  • 操作：在主库执行一个长时间未提交的大事务（如 BEGIN; 后执行大量 UPDATE 而不 COMMIT）。

  • 验证目标：观察从库是否会因为等待该事务提交而导致复制彻底停滞，以及此时系统的读写接口是否依然保持可用（即验证读操作是否能正确降级到其他正常副本）。

3. 可观测性建设的关键指标

针对主从复制架构，可观测性平台需要重点采集和展示以下维度的数据，以便在故障发生时能够快速定责和止血：

• 复制状态指标：

  • Slave_IO_Running / Slave_SQL_Running：确认复制线程是否存活。

  • Seconds_Behind_Master：量化延迟的具体秒数，这是判断从库是否健康的最核心指标。

• 线程状态指标：

  • 监控从库的 slave_sql_thread 状态。如果发现其长时间处于 Reading event from the relay log 或 Waiting for dependent transaction to commit，通常意味着遇到了大事务或大锁表。

• 连接池与路由指标：

  • 在网关或数据访问层，监控流向各个数据库节点的 QPS 分布。如果发生主从切换或节点宕机，应能直观看到流量百分比的剧烈变化。

主从复制解决了读的扩展性问题，但引入了数据一致性和分布式事务的复杂性。接下来的混沌实验建议重点放在“主从切换时的数据一致性校验”以及“从库宕机时的读流量转移极限测试”上。通过可观测性平台记录下切换过程中的 RT 变化、错误率以及最终一致性收敛的时间，这将为分布式核心项目组的稳定性建设提供极具价值的实战数据。

在 MySQL 的架构设计中，日志系统是保障数据持久化、高可用（Replication）以及实现事务特性的核心支柱。这三种日志各司其职，但在混沌工程实验中，它们的故障表现和监控重点截然不同。

一、 三种核心日志的深度解析与实验关联

1. Binlog（二进制日志）—— 主从复制与数据恢复的生命线

• 核心定位：Binlog 记录了所有对数据库的修改操作（DDL 和 DML），但不记录查询语句（SELECT）。它以追加写的方式记录，属于逻辑日志。

• 在混沌实验中的意义：它是 MySQL Replication 的唯一数据源。在之前的 MySQL 实验中，如果模拟了“主从网络延迟”或“从库宕机”，核心观测指标就是 Seconds_Behind_Master。当网络丢包或延迟注入时，从库的 I/O 线程拉取 Binlog 会变得困难，导致主从延迟飙升。

• 故障表现：如果 Binlog 写入失败（如磁盘满），主库的写操作会被阻塞，进而影响整个微服务的交易链路。

2. Redo Log（重做日志）—— 崩溃恢复的保障

• 核心定位：Redo Log 记录的是数据页的物理修改。它的存在是为了解决“内存易失性”与“磁盘持久性”之间的矛盾。

• 运行机制（WAL 机制）：MySQL 在修改数据时，会先将修改写入内存（Buffer Pool），然后立即写入 Redo Log Buffer，最后再刷盘到 Redo Log 文件。数据页的刷盘（Checkpoint）是异步且滞后的。

• 在混沌实验中的意义：Redo Log 是应对“操作系统崩溃”或“MySQL 进程意外 Kill -9”的关键。在混沌实验中，可以模拟磁盘 I/O 性能下降（如使用 blade create disk burn 占用 IOPS），观察 Redo Log 的刷盘延迟是否会导致数据库整体的 TPS（每秒事务数）下降，甚至引发事务提交阻塞。

3. Undo Log（回滚日志）—— 事务隔离与 MVCC 的基石

• 核心定位：Undo Log 记录的是数据被修改前的旧版本状态。它主要用于事务的回滚（Rollback）以及实现多版本并发控制（MVCC）。

• 运行机制：当事务修改一行数据时，MySQL 会将这行数据的旧值拷贝到 Undo Log 中。如果另一个事务需要读取这行数据，但当前事务尚未提交，数据库可以通过 Undo Log 找到数据的历史版本提供给读请求。

• 在混沌实验中的意义：Undo Log 与长事务（Long Transaction）强相关。可以设计实验：在数据库中开启一个不提交的事务，并不断修改大量数据。这会迅速耗尽 Undo TableSpace（回滚表空间）。此时再去执行其他写操作，可能会因为找不到可用的 Undo 段而报错（ERROR 1206 (HY000): The used table type doesn't support FULLTEXT indexes 或更常见的 Out of undo tablespace）。

二、 分布式系统视角的故障传导分析

在微服务架构中，这三种日志的异常最终都会转化为业务层面的不可用：

1. Binlog 异常导致的“读扩散”：

   • 场景：从库因为网络抖动（上一轮实验的 60% 丢包）导致复制停滞，Seconds_Behind_Master 达到 600 秒。

   • 传导：业务侧配置了读写分离，读请求被路由到该从库。用户看到的都是 10 分钟前的数据（Stale Read）。如果是支付状态查询，会引发严重的客诉。

2. Redo Log 瓶颈导致的“写阻塞”：

   • 场景：通过 ChaosBlade 对数据库服务器注入磁盘高延迟故障。

   • 传导：Redo Log 刷盘变慢，导致 InnoDB 存储引擎的事务提交必须等待。应用层的数据库连接池被占满，所有依赖该数据库的微服务实例开始出现大量的 ConnectionTimeout，进而导致整个系统的订单创建、库存扣减功能瘫痪。

3. Undo Log 耗尽导致的“全局锁死”：

   • 场景：某个定时任务或报表查询未正确关闭事务，导致 Undo Log 暴增。

   • 传导：其他正常的事务因为无法分配新的 Undo 空间而挂起。此时即使是简单的 INSERT 操作也无法执行，数据库进入“假死”状态。

三、 可观测性建设：如何监控“看不见”的日志

针对这三种日志，可观测性平台需要采集以下关键指标，以便在混沌实验中精准定位根因：

 

日志类型	核心监控指标	观测工具/位置	异常阈值建议
Binlog​	Binlog_cache_use / Binlog_cache_disk_use	Prometheus (MySQL Exporter)	Disk Use 比例过高，说明事务过大，容易撑爆 Binlog 文件。
	Seconds_Behind_Master	Prometheus / Grafana Dashboard	> 60s，判定主从延迟严重，触发告警。
Redo Log​	Innodb_log_waits	Prometheus	> 0，表示 InnoDB 被迫等待 redo log 刷盘，这是严重的性能瓶颈信号。
	Innodb_os_log_written (速率)	Prometheus	监控 Redo Log 的生成速率，评估磁盘 I/O 压力。
Undo Log​	Innodb_rollback_segments 使用情况	Performance Schema	观察活跃的 Undo 段数量，判断是否被长事务耗尽。
	Table_locks_waited / Table_locks_immediate	Prometheus	锁等待比例激增，可能是 Undo 不足导致的全局锁竞争。

四、 下一步行动建议：构建数据库韧性基线

为了将混沌工程的理论落地，建议分布式核心项目组开展以下实验，并由可观测性平台记录全过程：

1. 实验目标：验证主从切换时的数据一致性。

   • 操作：利用 ChaosBlade 模拟主库宕机（blade destroy 主库进程），观察从库是否能迅速提升为主库（Promote）。

   • 观测：使用 pt-table-checksum 或 pt-table-sync 工具，在主从切换前后比对关键业务表的数据一致性。

2. 实验目标：验证长事务对系统吞吐量的影响。

   • 操作：在业务低峰期，手动开启一个长事务并执行大数据量更新。

   • 观测：观察微服务的 RT 变化、数据库连接池活跃线程数变化，以及 Undo Log 文件大小的增长趋势。

     • 

MySQL 的主从异步复制机制利用了 Binlog 实现了数据的最终一致性。其核心流程是：Master 节点在完成事务提交后，将变更写入 Binlog；Slave 节点的 I/O 线程主动拉取这些日志并写入本地的中继日志（Relay Log），随后由 SQL 线程解析并应用这些日志。

然而，正如文中明确指出的，这种“异步”机制存在一个天然的、也是分布式核心系统最惧怕的缺陷：缺乏强一致性保证。

一、 缺陷深度剖析：异步复制的致命隐患

在实际的分布式微服务架构中，这两个缺陷会引发灾难性的“脑裂”或“数据丢失”事故：

1. 数据可能会丢失（主节点宕机）：

   • 场景：客户端向 Master 发送了一条写请求，Master 成功将事务写入 Binlog 并提交了事务（此时客户端收到了成功的响应）。但在 Master 将这个“写操作通知”发送给 Slave 的 I/O 线程之前，Master 节点突然因为硬件故障或内核 OOM 被杀死了。

   • 后果：由于 Slave 还没有收到这条最新的 Binlog，当运维人员强行将 Slave 提升为新 Master 时，那条已经对客户生效的写请求就会凭空消失，造成严重的资损。

2. 主从数据延迟可能会非常大（雪崩的导火索）：

   • 场景：Slave 通常是单线程（在老版本或默认配置下）回放 Master 的 Binlog。如果 Master 上执行了一个耗时极长的大事务（例如：批量更新千万级用户的积分），或者遭遇了秒杀级别的高并发写入。

   • 后果：Slave 的 SQL 线程会被长时间阻塞，导致 Seconds_Behind_Master（从库延迟时间）飙升至几分钟甚至几小时。此时，如果业务侧配置了读写分离，大量的读请求被路由到这个落后的 Slave 上，用户就会读到“脏数据”（比如订单明明已经付款，却还显示在购物车中）。

二、 针对异步复制的混沌实验设计

结合之前使用的 ChaosBlade 工具和之前探讨的网络故障场景，为了验证系统在数据库层面的高可用性和熔断能力，可以设计以下针对性的混沌实验：

1. 实验目标：模拟“主从网络闪断”与“脑裂”恢复

• 操作：在 Master 和 Slave 之间正常运行时，使用 ChaosBlade 对它们之间的内网链路注入 80% 的丢包率（参考第一轮的实验命令）。

• 预期现象：

  • Slave 的 I/O 线程会因为无法连接 Master 而报错（如 Got a fatal error）。

  • 监控平台（Prometheus）中应看到 Slave_IO_Running 变为 No，且 Seconds_Behind_Master 开始无限增大。

• 观测重点：观察应用的网关层或中间件（如 ShardingSphere-Proxy）是否会将读流量自动剔除该 Slave 节点，防止用户读到过期数据。

2. 实验目标：模拟“大事务导致的级联阻塞”

• 操作：在 Master 上手动开启一个事务，执行一个耗时 5 分钟的复杂 JOIN 或 UPDATE 操作，且不提交（Commit）。

• 预期现象：

  • Master 的 Binlog 处于锁定状态，无法刷新。

  • Slave 的 SQL 线程也会因为等待 Master 的 Binlog 事件而停滞。

• 观测重点：观察微服务的日志中是否出现大量针对该库的 Lock wait timeout exceeded 或 Connection timeout。验证系统的 Hystrix 熔断机制是否能在数据库无响应时，快速切断请求链，保护前端用户体验。

三、 可观测性建设：数据库层面的关键指标

为了精准捕捉上述实验产生的故障，作为可观测性平台负责人，需要在数据库监控大盘中重点关注以下指标：

1. Seconds_Behind_Master（从库延迟时间）：

   • 阈值告警：当该值大于 10 秒时发出 Warning，大于 60 秒时发出 Critical。

   • 意义：这是衡量数据库读写分离可用性的核心指标。

2. Slave_SQL_Running_State（从库 SQL 线程状态）：

   • 状态监控：正常情况下为空或 Reading event from the relay log。如果出现 Waiting for dependent transaction to commit，说明遇到了大事务或死锁。

3. Threads_connected（数据库连接数）：

   • 关联分析：当主从延迟发生时，观察连接数是否激增。这通常意味着应用端的连接池正在积压，等待数据库响应。

四、 总结与建议

异步复制虽然性能高，但在金融级或强一致性要求的分布式核心业务中，其风险极高。建议分布式核心项目组在进行混沌实验时，不仅要验证业务系统在发生故障时能否“活着”，更要验证在故障恢复后，系统能否通过数据校验工具（如 pt-table-checksum）发现并修复潜在的数据不一致问题。

 

半同步复制（Semi-Synchronous Replication）​ 是为了解决传统异步复制“数据易丢失”这一致命缺陷而设计的折中方案。

一、 机制深度剖析：从“尽力而为”到“确认到达”

图片清晰地展示了半同步复制的核心流程，其与异步复制的本质区别在于第 3 和第 4 步：

1. Master 提交的前提条件变了：在异步复制中，Master 只要把 Binlog 写到本地磁盘（落盘）就认为事务完成了，可以立即给客户端返回 Commit OK。而在半同步复制中，Master 必须等待 Slave 的 ACK（确认）信号。只有在收到 Slave 返回的“我已完整收到该事务的 Binlog”消息后，Master 才会给客户端返回 Commit OK。

2. Slave 的角色变了：Slave 不再是被动的“拉取者”，而是在接收到 Binlog 并刷盘后，主动向 Master 发送确认信号。

带来的收益：

这就保证了只要客户端收到了提交成功的响应，那么至少会有一台 Slave 已经接收到了这份数据。在极端情况下（Master 宕机），数据不会像异步复制那样完全丢失，极大降低了主从切换后数据不一致的风险。

二、 半同步复制的潜在风险与混沌实验视角

尽管半同步复制增强了数据安全性，但它引入了新的交互环节（网络往返 RTT），这在分布式系统中是一把双刃剑。结合之前的网络故障场景，可以设计以下实验来测试系统的韧性：

1. 实验目标：模拟“网络延迟导致的 ACK 超时”

• 操作：Master 和 Slave 正常同步时，使用 ChaosBlade 在两者之间注入 200ms 的网络延迟（或 50% 丢包）。

• 预期现象：

  • Master 在提交事务时需要等待 Slave 的 ACK，由于网络变慢，客户端会明显感觉到写操作的 RT（响应时间）变长。

  • 如果设置的超时时间（rpl_semi_sync_master_timeout）较短，半同步复制会自动退化成异步复制。此时 Master 不再等待 ACK，性能恢复，但数据一致性又回到了最初的风险状态。

• 观测重点：监控 Master 的错误日志，观察是否出现 Semi-sync replication slave was disconnected 或退化提示。

2. 实验目标：Slave 节点宕机的故障转移

• 操作：在半同步复制正常工作时，突然 Kill 掉 Slave 节点的 MySQL 进程。

• 预期现象：

  • Master 在超时等待后，会判定该 Slave 失效，并将其踢出半同步复制组。

  • 此时 Master 上的写操作虽然不再卡顿，但变成了“单机提交”。

• 观测重点：验证监控系统是否能迅速感知到 Slave 下线，以及 Master 的半同步状态是否及时回退到异步模式，确保业务写入不因 Slave 的短暂故障而彻底中断。

三、 可观测性建设：新增核心监控指标

针对半同步复制架构，除了常规的 QPS、TPS、主从延迟外，还需要增加以下维度的监控：

 

监控指标	含义	预警场景
Rpl_semi_sync_master_status​	Master 当前的半同步状态（ON=开启且正常，OFF=超时退化为异步）	状态频繁在 ON/OFF 之间跳动，说明网络极不稳定或 Slave 性能极差。
Rpl_semi_sync_master_clients​	当前有多少个 Slave 注册了半同步复制	数值下降，说明有 Slave 掉线或与 Master 失联。
Rpl_semi_sync_master_tx_avg_wait_time​	平均事务等待 ACK 的时间（微秒）	该值持续升高，说明网络延迟变大，写性能正在恶化。

四、 总结与行动建议

半同步复制是在“性能”与“数据一致性”之间取得平衡的经典方案。

下一步行动建议：

建议分布式核心项目组在测试环境中搭建一套半同步复制的 MySQL 集群，并利用 ChaosBlade 进行上述的“网络延迟”和“Slave 宕机”实验。重点观察当网络抖动导致半同步退化为异步时，业务系统是否有相应的告警，以及当 Slave 恢复后，数据是否能自动追平。这些实战数据将为生产环境的数据库选型和高可用架构设计提供宝贵的决策依据。

 

 

 

 

 

 

半同步复制（Semi-Synchronous Replication）通过引入一个关键的“确认”环节，有效地弥补了纯异步复制在数据安全性和主从一致性上的天然缺陷。

一、 机制深度剖析：从“尽力而为”到“确认到达”

与异步复制相比，半同步复制的核心变化在于Master 提交的前提条件。

1. 异步复制的隐患：在异步模式下，Master 只要把 Binlog 写到本地磁盘（落盘），就认为事务完成了，会立刻给客户端返回 Commit OK。如果此时 Master 立刻宕机，而 Slave 还没来得及拉取这份 Binlog，那么这条数据就永久丢失了。

2. 半同步的改进（ACK 机制）：半同步复制强制 Master 在给客户端发送成功响应之前，必须先确认至少有一个 Slave 已经接收到了这份 Binlog 数据。

   • 流程变化：Master 在收到客户端的 Commit 请求后，会将事务写入 Binlog，然后暂停等待。Slave 的 I/O 线程拉取到数据并写入自己的 Relay Log 后，会向 Master 发送一个 ACK（确认）信号。只有当 Master 收到这个 ACK，确认 Slave “签收”了数据，Master 才会最终给客户端返回 Commit OK。

带来的收益：这就保证了只要客户端收到了提交成功的响应，那么至少会有一台 Slave 已经接收到了这份数据。在极端情况下（Master 宕机），数据不会像异步复制那样完全丢失，极大降低了主从切换后数据不一致的风险。

二、 半同步复制的潜在风险与混沌实验视角

尽管半同步复制增强了数据安全性，但它引入了新的交互环节（网络往返 RTT），这在分布式系统中是一把双刃剑。结合之前的网络故障场景，可以设计以下实验来测试系统的韧性：

1. 实验目标：模拟“网络延迟导致的 ACK 超时”

• 操作：Master 和 Slave 正常同步时，使用 ChaosBlade 在两者之间注入 200ms 的网络延迟（或 50% 丢包）。

• 预期现象：

  • Master 在提交事务时需要等待 Slave 的 ACK，由于网络变慢，客户端会明显感觉到写操作的 RT（响应时间）变长。

  • 如果设置的超时时间（rpl_semi_sync_master_timeout）较短，半同步复制会自动退化成异步复制。此时 Master 不再等待 ACK，性能恢复，但数据一致性又回到了最初的风险状态。

• 观测重点：监控 Master 的错误日志，观察是否出现 Semi-sync replication slave was disconnected 或退化提示。

2. 实验目标：Slave 节点宕机的故障转移

• 操作：在半同步复制正常工作时，突然 Kill 掉 Slave 节点的 MySQL 进程。

• 预期现象：

  • Master 在超时等待后，会判定该 Slave 失效，并将其踢出半同步复制组。

  • 此时 Master 上的写操作虽然不再卡顿，但变成了“单机提交”。

• 观测重点：验证监控系统是否能迅速感知到 Slave 下线，以及 Master 的半同步状态是否及时回退到异步模式，确保业务写入不因 Slave 的短暂故障而彻底中断。

三、 可观测性建设：新增核心监控指标

针对半同步复制架构，除了常规的 QPS、TPS、主从延迟外，还需要增加以下维度的监控：

 

监控指标	含义	预警场景
Rpl_semi_sync_master_status​	Master 当前的半同步状态（ON=开启且正常，OFF=超时退化为异步）	状态频繁在 ON/OFF 之间跳动，说明网络极不稳定或 Slave 性能极差。
Rpl_semi_sync_master_clients​	当前有多少个 Slave 注册了半同步复制	数值下降，说明有 Slave 掉线或与 Master 失联。
Rpl_semi_sync_master_tx_avg_wait_time​	平均事务等待 ACK 的时间（微秒）	该值持续升高，说明网络延迟变大，写性能正在恶化。

四、 总结与行动建议

半同步复制是在“性能”与“数据一致性”之间取得平衡的经典方案。它通过牺牲少量的写延迟（等待网络 RTT），换取了极高的数据安全性（不丢数据）。

下一步行动建议：

建议分布式核心项目组在测试环境中搭建一套半同步复制的 MySQL 集群，并利用 ChaosBlade 进行上述的“网络延迟”和“Slave 宕机”实验。重点观察当网络抖动导致半同步退化为异步时，业务系统是否有相应的告警，以及当 Slave 恢复后，数据是否能自动追平。这些实战数据将为生产环境的数据库选型和高可用架构设计提供宝贵的决策依据。