物理 Online DDL 如何保存DDL 期间增量数据？

TiDBer_rdb3y58G · 2024 年7 月 28 日 13:43

物理的online ddl ，假设时修改2亿数据的列类型，需要半个小时，然后着半个小时不断的dml 进来共100w 数据变化。
请教下：
1. DDL 期间这个100w 数据变化时如何保存的。
2. 原本的2亿数据变更完后，是否需要先锁表，再应用增量的100w数据变化，如果不需要，如何保证数据一致性？

哪里有材料可以看呢，官网貌似没说这个。我看是有innodb_online_alter_log_max_size 这个参数的，不知道是否跟mysql 的原理一样

YuchongXU · 2024 年7 月 28 日 21:16

不需要锁表，在线的

AN_12 · 2024 年7 月 29 日 00:18

可以了解下F1 online Schema Change

TiDBer_iLonNMYE · 2024 年7 月 29 日 00:19

您需要了解一下DDC（data defin coprocessor）和OCC（Optimistic Concurrency Control）乐观并发控制。

yiduoyunQ · 2024 年7 月 29 日 01:11

github.com

ngaut/builddatabase/blob/master/f1/schema-change.md

# 异步 schema 变更

## 为什么在分布式系统中异步变更 schema 比较困难

F1 中的 schema 变更是在线的、异步的，schema 变更的过程中所有数据保持可用，保持数据一致性，并最大限度的减小对性能的影响。最大的难点在于所有 F1 服务器的 schema 变更是无法同步的，也就是说不同的 F1 服务器会在不同的时间点切换至新 schema。

由于所有的 F1 服务器共享同一个 kv 存储引擎，schema 的异步更新可能造成严重的数据错乱。例如我们发起给一次添加索引的变更，更新后的节点会很负责地在添加一行数据的同时写入一条索引，随后另一个还没来得及更新的节点收到了删除同一行数据的请求，这个节点还完全不知道索引的存在，自然也不会去删除索引了，于是错误的索引就被遗留在数据库中。

## 深度剖析 Google F1 的 schema 变更算法

### 算法思想

为了更好地阐释算法思想，本节我们以一个简化的情境做类比。

假想我们有一家跨国公司，公司员工分布在全球各地，员工之间以电子邮件的方式互相通信，同时工作的性质要求员工之间发送的消息不能出现丢失。之后在某一天出现这样的需求：管理层决定把员工通信方式由邮件改为 QQ。

对于这样一个跨国公司来说，我们无法瞬间把新的工作方式通知给所有员工。假如先收到通知的员工先改为用 QQ 了，而未收到通知的员工还在用邮件，这样一来自然就会发生大量的消息丢失。

那么我们能不能通知员工在未来的某个时刻统一换用 QQ 呢？仔细一想也是不行的。因为每个员工的手表不可能是完全对准的，总是有的快点有的慢点，只要不能保证所有员工的时间完全校准，总有那么一个不一致的时刻。

This file has been truncated. show original

github.com

ngaut/builddatabase/blob/master/f1/schema-change-implement.md

# TiDB 的异步 schema 变更实现

## 背景
  现在一般数据库在进行 DDL 操作时都会锁表，导致线上对此表的 DML 操作全部进入等待状态（有些数据支持读操作，但是也以消耗大量内存为代价），即很多涉及此表的业务都处于阻塞状态，表越大，影响时间越久。这使得 DBA 在做此类操作前要做足准备，然后挑个天时地利人和的时间段执行。为此，架构师们在设计整个系统的时候都会很慎重的考虑表结构，希望将来不用再修改。但是未来的业务需求往往是不可预估的，所以 DDL 操作无法完全避免。由此可见原先的机制处理 DDL 操作是令许多人都头疼的事情。本文将会介绍 TiDB 是如何解决此问题的。

## 解决方案
  根据 Google F1 的在线异步 schema 变更算法实现，并做了一些简单优化。为了简化设计，整个系统同一时刻只允许一个节点做 schema 变更。这里先说明一下，本文不会讲述 Google F1 schema 算法推导过程，对此算法不了解的可以直接阅读[论文原文](http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf)或者[本书前一章节](schema-change.md)。

## DDL的分类：
由于 bootstrap 操作时需要修改 DDL，这样就产生了鸡生蛋，蛋生鸡的依赖问题。所以需要将 DDL 分成两类，静态 DDL 和动态 DDL。系统 bootstrap 阶段只使用静态 DDL，同时必须在一个事务内完成，而后续所有的操作只允许使用动态 DDL。

## 引入新概念：
*   **元数据记录**：为了简化设计，引入 system database 和 system table 来记录异步 schema 变更的过程中的一些元数据。
*   **State**：根据 F1 的异步 schema 变更过程，中间引入了一些状态，这些状态要和 column，index， table 以及 database 绑定， state 主要包括 none, delete only, write only, write reorganization, public。前面的顺序是在创建操作的时候的，删除操作的状态与它的顺序相反，write reorganization 改为 delete reorganization，虽然都是 reorganization 状态，但是由于可见级别是有很大区别的，所以将其分为两种状态标记。
*   **Lease**：同一时刻系统所有节点中 schema 最多有两个不同的版本，即最多有两种不同状态。正因为如此，一个租期内每个正常的节点都会自动加载 schema 的信息，如果不能在租期内正常加载，此节点会自动退出整个系统。那么要确保整个系统的所有节点都已经从某个状态更新到下个状态需要 2 倍的租期时间。
*   **Job**： 每个单独的 DDL 操作可看做一个 job。在一个 DDL 操作开始时，会将此操作封装成一个 job 并存放到 job queue，等此操作完成时，会将此 job 从 job queue 删除，并在存入 history job queue，便于查看历史 job。
*   **Worker**：每个节点都有一个 worker 用来处理 job。
*   **Owner**：整个系统只有一个节点的 worker 能当选 owner 角色，每个节点都可能当选这个角色，当选 owner 后 worker 才有处理 job 的权利。owner 这个角色是有任期的，owner 的信息会存储在 KV 层中。worker定期获取 KV 层中的 owner 信息，如果其中 ownerID 为空，或者当前的 owner 超过了任期，则 worker 可以尝试更新 KV 层中的 owner 信息（设置 ownerID 为自身的 workerID），如果更新成功，则该 worker 成为 owner。在租期内这个用来确保整个系统同一时间只有一个节点在处理 schema 变更。
*   **Background operations**：主要用于 delete reorganization 的优化处理，跟前面的 worker 处理 job 机制很像。所以引入了 background job， background job queue， background job history queue， background worker 和 background owner，它们的功能跟上面提到的角色功能一一对应，这里就不作详细介绍。

该文件已被截断。显示原文

system · 2024 年9 月 27 日 01:12

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。