DDL 流程

OceanBase 数据库支持传统数据库的 DDL 语句，DDL 类型的 SQL 语句不会被优化器处理，而是作为 command 发送到 RootServer，由 RootServer 进行处理，比如典型的建表语句。在 OceanBase 数据库上的执行流程如下图所示：

image

DDL 产生的 schema 信息使用内部表记录，优点如下：

  • 直接利用 SQL 的事务及持久化能力

  • schema 变更信息可以通过 SQL 语句直接获取，避免了多集群之间的同步

  • 天然地享受 OceanBase 数据库自身的多副本容灾特性

由于支持多节点自动同步以及多版本，OceanBase 数据库内部很多的功能模块都设计成了类 DDL 语句，所以 OceanBase 数据库的 DDL 已经是个庞大的模块系统，包括：

  • tenant

  • user

  • database

  • table

  • table_group/partition_group

  • outline

  • planbase_line

  • package

  • privilege

  • synonym

Schema 多版本

对于单机数据库，schema 对多版本的需求并不强，只需保证 schema 变更的时序性。典型的实现中，通过 DML 与 DDL 之间的锁来保持时序性。OceanBase 数据库中 schema 支持多版本的需求体现在如下几个方面：

  • DML 与 DDL 互相不阻塞，提高性能。

  • 分布式事务

    对于分布式执行计划，多个机器上的 schema 必须保持一致。

  • 版本冻结

    OceanBase 数据库是存储架构基于 LSM-Tree，当内存增量数据达到阈值时需要冻结。发起冻结的 leader 需要将 schema 的版本同步给 follower， follower 才能冻结。

  • 分区合并

    OceanBase 数据库总是先冻结后合并，合并是延后调度的，当执行合并时，需要取相应冻结点的 schema。

  • 异构同步

    OceanBase 数据库的数据同步到其它数据库中时，是基于事务日志回放来完成的。解析历史事务日志时，需要获取相对应的 schema 信息。

为了支持多版本，需要将表的变更信息全部持久化到内部表中，包括删除动作，多版本 schema 内存管理如下图所示:

image

集群同步

所有 DDL 都会被转发给 RS 来统一调度。将 schema 从内部表 load 到内存的过程称为刷 schema。RootServer 执行内部表的更新后，需要将 schema 刷到最新，以保持最新的 schema 信息。然后将新的版本号通知所有在线的 OBServer，每个 OBServer 都收到通知后，此 DDL 即可正常返回。除了正常通知外，心跳包也会将最新版本号发给每个 OBServer。当OBServer 收到 DDL 变更后的版本号后，构造刷 schema 任务以刷新此 OBServer 的 schema。

全量刷新与增量刷新

Schema 的更新分为全量和增量两种，具体的更新流程如下图所示：

image