第17章: OzOSC - 零停机在线表结构变更
概述: 本章介绍 OzOSC（Online Schema Change）在线表结构变更机制的设计与安全边界。针对 MySQL 与 MariaDB 生产环境的大型数据表，提供可靠的零停机 DDL 执行与容灾恢复控制。
本章内容:
17.1 核心问题与挑战
在业务高峰期的核心生产表上直接运行标准 ALTER TABLE 命令，极易引发严重事故：
- 表级锁定 (Table Lock): 引擎排他锁阻断并发的读写操作。
- 业务中断与雪崩 (Downtime): 连接池耗尽，前端请求大面积超时崩溃。
- 主从复制延迟: 备库产生不可接受的高延迟，威胁读写分离集群的数据一致性。
OzOSC 采用只读先验模式（检查连接、元数据、服务器指纹及主键有效性）。受保护的执行管线会建立已验证的快照备份，初始化影子表（Shadow Table），按分块（Chunk）迁移历史数据，并在各项校验严格通过后才执行最终的原子切换（Atomic Swap）。任何不完整证据均会触发严格的 Fail-Closed 熔断。
17.2 当前技术支持边界
OzOSC 当前原生支持具备经过验证的主键及受支持元数据的 MySQL/MariaDB 数据表。SQLite 与 PostgreSQL 环境不使用此 OSC 路径。包含不支持的虚拟计算列、复杂外键或预存触发器的表将在评审阶段予以拦截。
17.3 预定执行流程
[ 线上生产表: orders ] --(触发器增量同步)--> [ 影子表: _orders_sqloz_osc ]
(读写请求保持正常无感知) (执行 ALTER TABLE 变更)
|
(原子切换 RENAME − 1 毫秒)
v
[ 线上全新表: orders ]受防护的执行阶段：
- 创建影子表: 校验完成后，克隆出与原表结构相同但独立的空影子表。
- 应用结构变更: 在空影子表上执行
ALTER TABLE，耗时仅几毫秒。 - 触发器增量镜像: 安装临时触发器，将数据复制期间原表发生的
INSERT、UPDATE、DELETE同步复制至影子表。 - 分块批量数据迁移: 在受控速率下分批拷贝原存数据，避免对生产负载与主从复制带来冲击。
- 原子表切换 (Atomic Swap): 校验完毕后，通过原子级
RENAME TABLE瞬间切换新旧表名称。旧表将保留直至清理阶段验证完毕。
如执行过程中发生网络异常或中断，可在 OzOSC 控制面板打开 Refresh Recovery：
- Complete cleanup: 切换成功后彻底清除触发器与影子表。
- Resume copy: 基于检查点安全续传未完成的数据拷贝。
- Abort preparation: 在安全状态下安全清除影子表及触发器，完整保留原表与备份。
警告: MySQL/MariaDB DDL 本身不支持事务回滚。OzOSC 在检测到不可预期证据时将主动阻断操作，优先保障数据万无一失。
17.4 实时进度跟踪与状态监控
- 实时迁移速率 (Rows/sec): 每秒转移的记录数。
- 预计剩余时间 (ETA): 基于当前吞吐量的精准完工预估。
- 安全取消控制: 发出取消指令后，系统将安全展开清理并报告确切的状态结余。