Note:
Original topic: 什么是DDL租约？
There is a configuration called lease on the TiDB instance. What is a DDL lease?
`lease`
DDL lease timeout.
Default value: 45s
Unit: seconds
Is it the retention time of the owner role of the TiDB server responsible for executing DDL jobs?
You can refer to this article:
# 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，它们的功能跟上面提到的角色功能一一对应，这里就不作详细介绍。
show original
What I understand is: the time period from when the owner starts executing DDL to when the DDL status is modified.TiDB 集群管理常见问题 | PingCAP 文档中心
This topic was automatically closed 1 minute after the last reply. No new replies are allowed.
|
username: ddhe9527
|
username: 
|
username: 
|
username: 
|
username: