TiDB 学习笔记一（运维管理）[通俗易懂]

 1.截至 4.0 版本，TiDB 与 MySQL 的区别总结

2.TiDB DDL操作

TiDB 集群中，用户执行的 DDL 操作分两类：普通 DDL 操作和加索引操作。

增加字段

在执行 ADD COLUMN 类型 DDL 时，TIDB并没有对数据进行回填，而是将最新添加的列的 default 值保存到 schema 的”原始默认值”字段中，在读取阶段如果 TiKV 发现该列值为 null 并且”原始默认字段”不为 null，则会使用”原始默认字段”对该 null 列进行填充，并将填充后的结果从 TiKV 返回。通过这种优化，该 DDL 操作不需要关心表中实际行数，可以更快的完成 DDL 变更，操作执行时间短，一般秒级就可以执行完成。

增加索引

加索引操作由于需要回填数据，因此执行时间略长。而在回填数据期间，需要将回填的数据写入 TiKV，对 TiKV 会产生额外的写入压力，从而造成一些性能影响。

TiDB 提供了参数 tidb_ddl_reorg_worker_cnt 和 tidb_ddl_reorg_batch_size 用来控制回填数据的速度。通过调整参数，可以在业务访问高峰到来时降低 DDL 速度，保证对业务的正常访问无影响；而在业务访问低峰增加 DDL 速度，从而更快的完成 DDL 任务。

 3.Sequence

Sequence 是数据库系统按照一定规则自增的数字序列，具有唯一和单调递增的特性。可以实现并发应用需要获取单调递增的序列号；通过调用不同的Sequence ，在一张表里面需要有多个自增字段；更新数据表中一列值为连续自增的值。

 4.AutoRandom

AutoRandom 是 TiDB 4.0 提供的一种扩展语法，用于解决整数类型主键通过 AutoIncrement 属性隐式分配 ID 时的写热点问题。使用 AUTO_RANDOM 功能前，须在 TiDB 配置文件 experimental 部分设置 allow-auto-random = true。

• 唯一性：TiDB 始终保持填充数据在表范围内的唯一性。
• 高性能：TiDB 能够以较高的吞吐分配数据，并保证数据的随机分布以配合 PRE_SPLIT_REGION 语法共同使用，避免大量写入时的写热点问题。
• 支持隐式分配和显式写入：类似列的 AutoIncrement 属性，列的值既可以由 TiDB Server 自动分配，也可以由客户端直接指定写入。该需求来自于使用 Binlog 进行集群间同步时，保证上下游数据始终一致。

5. TiUP

在 TiDB 4.0 的生态系统里，TiUP 作为新的工具，承担着包管理器的角色，管理着 TiDB 生态下众多的组件（例如 TiDB、PD、TiKV）。用户想要运行 TiDB 生态中任何东西的时候，只需要执行 TiUP 一行命令即可，相比以前，极大地降低了管理难度。

 6.数据订阅复制同步工具 CDC

TiCDC（TiDB Change Data Capture）是用来识别、捕捉和输出 TiDB/TiKV 集群上数据变更的工具系统。它既可以作为 TiDB 增量数据同步工具，将 TiDB 集群的增量数据同步至下游数据库，也提供开放数据协议，支持把数据发布到第三方系统。相较于 TiDB Binlog，TiCDC 不依赖 TiDB 事务模型保证数据同步的一致性，系统可水平扩展且天然支持高可用。在 TiCDC 工具出现之前，数据同步功能是由 TiDB-Tools 工具中的 TiDB-Binlog 来实现的。TiDB-Binlog 通过收集各个 TiDB 实例产生的 binlog，并按照事务提交的时间排序后同步到下游。

 7.数据导入工具 Lightning

TiDB Lightning 是一个将全量数据高速导入到 TiDB 集群的工具，速度可达到传统执行 SQL 导入方式的 3 倍以上、大约每小时 300 GB。Lightning 有以下两个主要的使用场景：一是大量新数据的快速导入、二是全量数据的备份恢复。目前，Lightning 支持 Mydumper 或 CSV 输出格式的数据源。

 注意事项:一旦目标 TiKV 集群切换到导入模式，整个数据导入阶段该集群将被 tidb-lightning 独占，无法对外提供正常服务。数据导入完成后，tidb-lightning 会自动把 TiKV 集群切换回“普通模式”。

8.备份恢复工具 BR

 BR(https://github.com/pingcap/br) 是分布式备份恢复工具，分布式意味着可以通过 BR 可以驱动集群中所有 TiKV 节点进行备份恢复工作，相比起 SQL dump 形式，这种分布式备份恢复的效率会有极大的提升。

注意（1）增量的实现也是全表扫，同样有性能问题，这个和传统数据库的增量不一样；(2)恢复耗时要高于备份耗时。

9.导出工具Dumpling

Dumpling 将提供以下几个特性：

• 完全采用 Golang，与 TiDB 生态集成度高
• 能够提供 Mydumper 类似的功能，且支持并发高速导出 MySQL 协议兼容数据库数据
• 提供 SQL、CSV 等多种数据输出格式，以便于快速导出及导入
• 支持直接导出数据到云存储系统，比如 S3

 10.限制 SQL 内存使用和执行时间

限制SQL内存使用和执行时间主要是为限制消耗系统资源多的SQL，防止某条SQL造成OOM或影响到集群的整体性能。

11.利用 GC 快照读恢复数据

TiDB 事务的实现采用了 MVCC（多版本并发控制）机制，当更新/删除数据时，不会做真正的数据删除，只会添加一个新版本数据，并以时间戳来区分版本。当然历史数据不会永久保留，超过一定时间的历史数据将会被彻底删除，以减小空间占用，同时避免因历史版本过多引起的性能开销。

TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，默认情况下每 10 分钟一次。每次 GC 时，TiDB 会计算一个称为 safe point 的时间戳（默认为上次运行 GC 的时间减去 10 分钟），接下来 TiDB 会在保证在 safe point 之后的快照都能够读取到正确数据的前提下，删除更早的过期数据。

TiDB 的 GC 相关的配置存储于 mysql.tidb 系统表中，可以通过 SQL 语句对这些参数进行查询和更改。

 读取历史版本数据前，需设定一个系统变量: tidb_snapshot ，这个变量是 Session 范围有效级别，可以通过标准的 Set 语句修改其值。当这个变量被设置后，TiDB 会用这个时间戳建立 Snapshot（没有开销，只是创建数据结构），之后所有的查询操作都会在这个 Snapshot 上读取数据。当读取历史版本数据操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 “”，即可读取最新版本的数据。

12.利用 Recover/Flashback 命令秒恢复误删表

Recover

TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据范围（行数据和索引数据）写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。所以，RECOVER TABLE 只需要在 GC Worker 还没删除表数据前，恢复表的元信息并删除 mysql.gc_delete_range 表中相应的行记录就可以了。恢复表的元信息可以用 TiDB 的快照读实现，TiDB 中表的恢复是通过快照读获取表的元信息后，再走一次类似于 CREATE TABLE 的建表流程，所以 RECOVER TABLE 实际上也是一种 DDL。

recover table 的一些使用限制：

• 只能用来恢复误删除表的 DDL 操作，例如 truncate table，delete 操作没有办法恢复。
• 只能在 GC 回收数据之前完成，超过 GC 时间后会报错无法成功恢复。
• 如果在使用 binlog 的情况下，上游执行 recover table 可能会出现一些非预期的结果。例如下游是 MySQL 数据库，对于这个语法不兼容。上下游的 GC 策略配置不同，再加上复制延迟可能会引起下游的数据在 apply recover table 的时候已经被 GC 了从而导致语句执行失败。

Flashback

Flashback 的原理和 Recover table 比较类似，不过是 recover 的升级版，在覆盖 recover 的所有功能之外，还可以支持 truncate table 的操作，未来也会逐渐取代 recover 命令。

参考学习

１.TiDB In Action: based on 4.0

https://book.tidb.io/

２.走进TiDB社区

https://www.bilibili.com/video/av242591239

3.TiDB 数据库开发规范

https://asktug.com/t/topic/93819