Online Schema Change（在线更新元数据）

传统的关系型数据库在执行 Schema 变更时，为了保证数据一致性需要锁表，锁表期间任何读写操作都会受到阻塞，直到 Schema 变更结束，释放表锁。

这样做法使处理流程简单化，但同时弊端也很明显，那就是其他的 DML 操作都会受到阻塞，影响正常业务。

KaiwuDB 的 OSC 引进 2 个中间状态，通过控制过渡状态来保证数据一致性且不需要锁表，因而不影响正常业务。为方便后续理解，这里先罗列常见的 4 种 OSC 状态：

1、Absent此状态下 Schema 不存在，定义的对象不可用。Schema 对所有操作不可见，不可读写。

2、DescriptorMutation_DELETE_ONLY指变更的这部分 Schema 只对删除操作可见。

3、DescriptorMutation_DELETE_AND_WRITE_ONLY指变更的这部分 Schema 只对写操作可见，包括 Insert, Delete, Update。

4、PublicSchema 已完成变更，定义的对象完全可用。Schema 对所有操作可见，定义的对象可读可写。

接下来通过“Create Index"实例，介绍 KaiwuDB 在实际业务中如何保持数据一致性且不影响正常业务流程>>

第 1 步： 由 Absent 状态演进到 DELETE_ONLY 状态，Version+1，Mutation 对 Delete 操作可见；

第 2 步： 通过 waitToUpdateLeases 函数等待集群的其他节点将表元数据更新到 Version2，这期间 Version2 和 Version1 共存，此时在 Node2 插入业务数据，由于 DELETE_ONLY 状态下 Insert 对 Mutation 不可见，不会增加索引数据，所以不会出现数据不一致情况；

第 3 步： 由 DELETE_ONLY 状态演进到 DELETE_AND_WRITE_ONLY 状态，Version+1，Mutation 对 Insert 和 Delete 可见；

第 4 步： 通过 waitToUpdateLeases 函数等待集群的其他节点将表元数据更新到 Version3，这期间 Version3 和 Version2 共存，此时在 Node2 插入业务数据，由于 DELETE_AND_WRITE_ONLY 状态 Mutation 对 Insert 可见，所以会增加索引数据，Node1 还是 DELETE_ONLY 状态，Delete 业务数据能把对应的索引数据也删除，所以不会出现数据不一致情况；

第 5 步：可选，需要做数据回填的 DDL 语句（增加索引、删除列、增加带默认值的列）；

第 6 步：由 DELETE_AND_WRITE_ONLY 状态演进到 Public 状态，Version+1，Mutation 对 Insert、Delete 和 Read 可见；

第 7 步：通过 waitToUpdateLeases 函数等待集群的其他节点将表元数据更新到 Version4，这期间 Version4 和 Version3 共存，此时在 Node2 插入业务数据，由于 Public 状态 Mutation 对 Insert 可见，所以会增加索引数据。Node1 还是 DELETE_AND_WRITE_ONLY 状态，Delete 业务数据能把对应的索引数据也删除。相反 Node1 插入业务数据也会增加索引数据，Node2 删除业务数据也能删掉索引数据，所以不会出现数据不一致情况。

至此，完成了创建索引的变更，由于每 2 个版本是兼容的，所以完成变更之后能保证数据的一致性。最后为大家梳理一下整体的脉络流程：

1、执行算子，往表描述符添加变更操作 Mutation；

2、执行算子，生成 Job 信息，往 System.jobs 系统表插入信息；

3、将DDL（Data Definition Language） 事务状态转为 Commit；

4、通过 Channel 通知后台 Work 处理 Job；05后台 Work 遍历 System.jobs，找到 Lease 属于本节点且状态为 Running 的 Job，并为每个 Job 起一个 Goroutine 进行处理。