TiDB在360的落地及实战干货

TiDB在360的落地及实战干货

背景

 

Part1:写在最前

当一张百亿数据量的表放在你面前，你将面临着什么？

加列？哭吧，怎么也得等个几天甚至几周。加索引？哭吧，不论你用pt-online-schema，仍是gh-ost，你都面临着拷贝一张临时表用以存储临时数据，磁盘已经80%了，你这一张表就占几百G,你咋弄？～

我先说几个最让你兴奋和开心的点吧：

1. 在TiDB里，你彻底不用担忧磁盘容量的问题；

2. 在TiDB里，原生支持Online DDL，你彻底不用担忧第三方改表工具改表出现各类Bug的问题，相信用开源工具改过上T级别表的同窗都遇到过或多或少的各种error。

3. 在TiDB里，加列，主键扩容字段都是秒级的，好比我刚刚就刚对一张19亿的表加完了字段，1s完事儿～这在MySQL里要8.0才能够，并且还要求列在最后才行。

4. 在TiDB里，你会发现count(*)惊人的快，一张近20亿的表coun(*)大概在1分钟完事儿，固然，这取决于你的KV数量和磁盘性能。

5. 在TiDB里，从MySQL迁移将变得简单，图形化一键迁移，爽不爽？

6. 在TiDB里，绝大多数状况你会发现比单机MySQL有更好的性能，固然也不排除一些例外，例如enum这样奇葩的字段类型。
   

7. 在TiDB里，......，您且往下看，我慢慢和您说～

 

Part2:使用背景

360 云平台对 360 集团各大业务线均有提供服务支持，涉及的数据库支持方案有：MySQL、Redis、MongoDB、ES、GP、PiKA。其中 MySQL 至今已有过万的实例，目前，对于一些写入量大的业务，已经出现瓶颈。例如磁盘空间，虽然咱们能够经过分库分表的方式，拆分出来，但这对业务和 DBA 来讲都是不小的工做量，最痛苦的无异于这些大表的改表。不管是单表上T，仍是分库分表，对一张大表执行 DDL 的代价是很是大的。

针对业务爆发式增加的数据量，咱们开始调研选型是否有其余数据库能够代替传统的MySQL。经过调研咱们了解到 TiDB，迁移平滑，基本上无需业务变更代码，彻底的事务 ACID 支持，分布式的架构，自带高可用、Online DDL。

截止目前，360 云平台这边有三套 TiDB 集群，总节点数在 50+。有 9 个业务线接入使用，有过百亿级表 online 加索引的案例，总数据量目前在 80T。版本上，咱们从 3.0.1 一路跟随到 3.0.5，DM 版本从内测到 1.0.2 GA 版本，共计提出 9 个 BUG 或改进项反馈。后续咱们计划将 TiDB 上到 360 HULK 云平台上，并定制化开发一些功能为业务提供可视化的服务，以便让 360 集团更多的业务线接触到 TiDB、使用 TiDB。

版本的选择咱们之因此从大版本 3 开始，也是看到了一些 2.X 版本的社区反馈，尤为是索引执行计划这块，3.X 版本较以前的版本会好不少。DM 版本咱们是直接选取的最新版，后一路跟随新版本升级。

 

Part3:集群架构

 

 

 

总体架构上，咱们除了 TiDB 集群外，还用到了 DM 和 Pump、Drainer 套件，这块主要是因为咱们使用 TiDB 的业务有两种：

1.老的 MySQL 业务，因单机磁盘受限，致使单实例磁盘没法支撑爆炸式增加的数据量，数据比较重要，须要备份和支持 7*24 小时的恢复。这类业务咱们用到 DM 套件来实现无障碍迁移，1TB 的导入时间在 16 小时，这里若是是比较大的数据源，且 TiDB 是全新集群，可使用 TiDB-Lightning，速度能够更快。Lightning 的实测导入速度，37      分钟，导完 2 张大表共计 54G 的数据，符合 100G/H 预估。是 loader 的 3 倍速度， loader 用时 2 小时 4 分钟。提及      DM 使用这块文章后面会单独分享下这块须要注意的问题。以下图所示：

2.全新的业务，或由业务自行导入到 TiDB 集群中，这种业务数据量通常都会比较大，也是看中了 TiDB 支持 ACID 和分布式的特色。目前网盾业务有多张表都过 10 亿级别，其中有张表到达了 100亿+，建索引花了近      10 天（这块其实咱们应当注意，不是分布式就一张表就完事儿了，由于表量级过大，清理老旧数据都是个问题）。TiDB 如今支持分区表，但咱们在使用过程当中发现性能上和普通表有差距，期待后续版本可以让分区表功能和性能更加的完善。

TiDB在360云平台的使用状况

 

Part1:写在最前

对于这一全新的数据库，咱们本着大胆用，不拘泥于传统的态度进行使用。咱们的 MySQL 如今也正在适配 8.0 版本，MongoDB、ES 也都是时刻关注着新版本状况来评估是否适合云平台。所以 TiDB 的上线也是从离线业务-边缘业务-核心业务来过渡的。

通过大量的测试、也参考了其余公司的使用状况，咱们计划将 TiDB 归入 360 HULK 云平台，并计划后期对其不断完善在云平台中的功能，对全公司业务线开放使用。定制化开发一些 MySQL 已经具有的，例如 SQL 审核、慢查统计、冗余索引检测、自增索引阈值等各项基础功能等等。虽然在使用过程当中遇到了一些小问题，例如索引的选取、参数的调优，由于一些配置致使的性能抖动，但都获得了PingCAP同窗快速的响应和回复，这对咱们推动 TiDB 有重大的帮助，在此感谢 PingCAP 的戚铮和高振娇同窗。

 

Part2:一键迁移工具DM干货分享

DM 使用经验

权限

官网手册上只说明须要以下权限：

TiDB Lightning 须要如下权限：

SELECT

UPDATE

ALTER

CREATE

DROP

存储断点的数据库额外须要如下权限：

INSERT

DELETE

但实测过程当中发现还须要以下权限：

上游 （REPLICATION SLAVE 权限必须具有，要不增量同步会 access deny）；

下游 （不加 super 会致使 checksum table 没法执行）。

TiKV region score

PD 监控中 -Statistics-balance 中，有 Store-region-score 监控项，这里记录的是各个节点的 score 得分，正常状况下，咱们指望的结果是得分接近的，这说明无需进行 region 大规模迁移。

PD 调度原理

Region 负载均衡调度主要依赖 balance-leader 和 balance-region 两个调度器。两者的调度目标是将 Region 均匀地分散在集群中的全部 Store 上，但它们各有侧重：balance-leader 关注 Region 的 Leader，目的是分散处理客户端请求的压力；balance-region 关注 Region 的各个 Peer，目的是分散存储的压力，同时避免出现爆盘等情况。

咱们这里重点关注的是 balance-region，当它出现不均衡的时候，咱们能够直接在监控中看到相似下图所示：

 

调度期间，不可避免的会出现 IO 争用、磁盘的 lantency，都会出现不一样程度的上涨，从业务上的反馈看，就会出现积压，响应不及时等等。而当 region Balance 完成后， Duration 等都会恢复正常水平

所以，咱们要关注的地方有两点：

1. 如何控制或减少 region balance 大规模迁移时对业务的影响；

2. 如何提早规避因磁盘致使的大规模 region balance。

对于第一点，咱们迁移的时候是有参数能够控制的。

这里不管是磁盘空间阈值，仍是 region balance 调度速度，或者 drop 大量表后调整空 region merge 的速度，其实都是能够经过 pd-ctl 的 config set 命令来实时调节。

例如：

high-space-ratio 0.7 #设置空间充裕阈值为 0.7。当节点的空间占用比例小于指定值时，PD 调度时会忽略剩余空间这个指标，主要针对实际数据量进行均衡。

region-schedule-limit 8 #最多同时进行 8 个 Region 调度。 这个值主要影响 Region balance 的速度，值越大调度得越快，设置为 0 则关闭调度。Region 调度的开销较大，因此这个值不宜调得太大。也能够经过减少该值来限制调度region对集群产生的影响

merge-schedule-limit 12 #最多同时进行 12 个 merge 调度。设置为 0 则关闭 Region Merge。Merge 调度的开销较大，因此这个值不宜调得过大。

leader-schedule-limit 8 #最多同时进行 8 个 leader 调度。这个值主要影响 leader balance 的速度，值越大调度得越快，设置为 0 则关闭调度。Leader 调度的开销较小，须要的时候能够适当调大。

max-merge-region-keys 50000 #设置 Region Merge 的 keyCount 上限为 50k。当 Region KeyCount 大于指定值时 PD 不会将其与相邻的 Region 合并。

max-merge-region-size 16 #设置 Region Merge 的 size 上限为 16M。当 Region Size 大于指定值时 PD 不会将其与相邻的 Region 合并。设置为 0 表示不开启 Region Merge 功能。

TIPS：理解了做用和原理，上述参数均可以根据需求自行控制。

• 例如当咱们在 drop 大量的表后，会产生不少的空 region。

  在 Region 数量较多的状况下，Raftstore 须要花费一些时间去处理大量 Region 的心跳，从而带来一些延迟，致使某些读写请求得不到及时处理。若是读写压力较大，Raftstore 线程的 CPU 使用率容易达到瓶颈，致使延迟进一步增长，进而影响性能表现。

  所以咱们会但愿尽快的进行 region merge，来避免过多的 region 对集群形成性能损耗时，咱们能够同时调小 max-merge-region-keys、max-merge-region-size，来让其更快的触发 merge 操做，同时调大 merge-schedule-limit 提升并发度。

• 例如当咱们发现某台 KV 磁盘空间剩余 40% 开始大量调度时，咱们能够将 high-space-ratio 调整到 0.7，以临时避免调度对业务产生的影响。

  咱们也能够控制调度的并发度，来减小对业务产生的影响，实测这都是立竿见影的参数，你们若是遇到这些问题可供参考。

  对于第二点，尤为是使用 DM 期间，将 DM-worker 和 TiKV 混合部署的状况下，要注意清理全量备份留下的文件和 relaylog。

默认调度策略是当磁盘剩余的有效空间不足 40%，处于中间态时则同时考虑数据量和剩余空间两个因素作加权和看成得分，当得分出现比较大的差别时，就会开始调度。

因此 DM 导入完成后，要记得删除全量备份。就是 dumped_data.task_xxx 文件夹，这个全量备份通常都会比较大，若是 dm-worker 和 TiKV 混部，就会出现某个 TiKV 节点磁盘已使用率高于其余，这时 PD 的 store region score 就会相比其余节点出现异常，引发性能抖动和 duration 升高。

 

一直等待其追上后，才会像下图这样：

此时，balancer已达平衡状态：

Duration 恢复正常水平，以下图 16:54 分时的状况：

QPS也再也不积压，恢复正常水准：

关于 relay-log，默认是不清理的，就和 MySQL 的 expire_logs_days 同样，这块能够经过 dm-worker 的配置文件来进行配置，例如将 expires 配置为 7，表明 7 天后删除：

[purge]

interval = 3600

expires = 7

remain-space = 15

expires 来控制保留天数。

默认 expires=0，即没有过时时间，而 remain-space=15 意思是当磁盘只剩于 15G 的时候开始尝试清理，这种状况咱们极少会碰到，所以这个清理方式其实基本上是用不到的。因此建议有须要删除过时 relay-log 的小伙伴，直接配置 expires 保留天数就能够了。

DM 导入完成后，应该提供是否在完成后自动删除全备文件的选项，能够默认不删，由使用者决定是否删除。

从使用者角度来讲，全量备份目录不管是全量一次性导入仍是 all 增量同步，后续都不会再使用到。若是 dm-worker 和 TiKV 混部，会致使全备文件占据大量磁盘空间，引发 TiKV region 评分出现异常，致使性能降低，已转化为 PRM 产品需求。

关于 DM 使用期间出现数据丢失的问题

在早期尚未 dm-portal 自动化生成 task 时，咱们都是自行编写 DM 的 task 同步文件。后来有了 dm-portal 自动化生成工具，只要图形页面点点点就能够了。

但该工具目前有一个问题是，没有全库正则匹配，即使你只勾选一个库，他底层是默认把每张表都给你配置一遍。这就会出现当上层 MySQL 新建立某张表的时候，下游会被忽略掉，例如当你使用改表工具 gh-ost 或者 pt-online-schema-change，你的临时表都会被当作为不在白名单内而被忽略，这个问题使用者须要注意。咱们也已经反馈给了官方。将来不久的版本估计就能够修复。

["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD COLUMN `raw_url_md5` CHAR(32) NOT NULL DEFAULT '' COMMENT 'raw_url md5'"]

["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD INDEX `idx_rawurl_md5`(`raw_url_md5`)"] [schema=flow]

["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` DROP INDEX `idx_raw_url`"] [schema=flow]

这里日志能够看到 event 被 skip 了。

关于 DM 使用期间偶发性 1062 主键冲突的问题

query-error task 能看到具体的报错信息， 下游看都没有该值：

mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';

Empty set (0.00 sec)

再去上游看，结果发现也没有值，业务逻辑应该是后来 delete 了：

mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';

 

Empty set (0.00 sec)

由于上游也没有值，去上游看 Binlog 后分析以下：

是先写入，再删除，因此上游没值是能够预期的，可是下游尚未同步到这块，此时也是没有值的，不该该存在 1062 的问题。

当集群有大规模 kv:1062 报错时，或者集群写入压力大时，DM 从结果看没法保证 Binlog 的有序落盘，需确认 DM 能不能保证 lvs 下的多个 TiDB Binlog 的每个 event 是有序执行的。只从现象看，只要集群没有大量的 1062 报错，PD 相关的监控值都比较低，DM 也不会出现任何同步报错，反之就出现。从 Binlog 看就像是第一条 insert 了，还没来得及 delete，直接 insert 产生的报错，但报错后那个 delete 的也完成了，因此这时候我再怎么快也快不到毫秒级，下游看不到全部记录。解决的办法是将 1062 大量冲突的业务拆分出集群，或 DM 直接写 TiDB 的真实 ip 而不是 lvs。

DM 同步异常

有业务反馈 drop 分区和 drop 列时出现同步异常。补充下分区表相关的测试的结果，DM 更多的没法拆分的状况仍是在 drop 这块，普通的 add，modify 没问题的：

• 一次删除多个分区的操做则会报错：

  alter table dsp_group_media_report drop partition p202006 ,p202007 ;

• drop 含有索引的列操做会报错

  Alter table dsp_group drop column test_column;

  40 亿表添加 DDL 添加索引致使的 duration 升高

 

定位到是

mysql> show global variables like 'tidb_ddl_reorg_worker_cnt';

+---------------------------+-------+

| Variable_name             | Value |

+---------------------------+-------+

| tidb_ddl_reorg_worker_cnt | 16    |

+---------------------------+-------+

1 row in set (0.11 sec)

 

mysql> show global variables like 'tidb_ddl_reorg_batch_size';

+---------------------------+-------+

| Variable_name             | Value |

+---------------------------+-------+

| tidb_ddl_reorg_batch_size | 1024  |

+---------------------------+-------+

上述两个参数对已有非 pcie 集群压力比较大致使。

经过 set global 调节（3.0.3 后，默认从 256 涨到了 1000 和 16）：

tidb_ddl_reorg_batch_size 1000-256

tidb_ddl_reorg_worker_cnt 16-4

同时，提升 compaction 相关：

max-background-jobs: 8-10-12

max-sub-compactions: 1-2-4

defaultcf.compression-per-level: ["lz4", "lz4", "lz4", "lz4", "lz4", "zstd", "zstd"]

writecf.compression-per-level: ["lz4", "lz4", "lz4", "lz4", "lz4", "zstd", "zstd"]

最终的优化结果是，QPS 稳定在 3k 左右：

 

静默 region 开启

在实际状况中，读写请求并不会均匀分布到每一个 Region 上，而是集中在少数的 Region 上。那么能够尽可能减小暂时空闲的 Region 的消息数量，这也就是 Hibernate Region 的功能。无必要时可不进行 raft-base-tick，即不驱动空闲 Region 的 Raft 状态机，那么就不会触发这些 Region 的 Raft 产生心跳信息，极大地减少了 Raftstore 的工做负担。

截至 TiDB v3.0.5，Hibernate Region 还是一个实验功能，在 TiKV master 分支上已经默认开启。可根据实际状况和需求来开启该功能。参数以下：

raftstore.hibernate-regions: true

DM 导入期间 duration 升高

在 DM 导入集群期间，确实会由于写热点的问题致使集群总体 duration 更高，由于 IO 争用会更明显。这里其实也是能够经过一些参数来让集群运行的更快的。

以下参数从原值调到-新值：

raftstore:

apply-pool-size: 3-4

store-pool-size: 3-4

 

storage:

scheduler-worker-pool-size: 4-6

 

server:

grpc-concurrency: 4-6

 

rocksdb:

max-background-jobs: 8-10

max-sub-compactions: 1-2

能够看到效果以下：

QPS 再也不抖动，duration 也恢复到正常的水平。

DM Debug 相关

DM 还有个注意点就是 dm-worker.toml 配置文件里的配置 log-level = “debug” 是不生效的，启动的时候默认有个 -L=info 选项，会覆盖掉配置文件里的，默认 -L 优先级高于配置文件，人工排查时自行启动。也就是说当须要对 dm-worker 开启 debug 模式，要人工拉起进程并指定 -L 选项 =debug。

TiDB load data 速度不理想

TiDB 目前 load data 的导入速度不及 MySQL，若是依赖 load data 的话，这块能够调优一下参数。咱们的场景是 TiKV 上没有明显的瓶颈，主要慢在了 scheduler latch wait duration，能够调下参数看看:

storage:

scheduler-concurrency: 204800000

 

raftstore:

raft-max-inflight-msgs: 4096

调优完成后是有提高，但提高不大，咱们得知新版本的 TiDB 在Load data 这块又有速度提高，比较期待新版本。

Part3:其余干货打包分享

TiDB 列数超限

MySQL 是 1024，TiDB 目前限制是 512 列。若是你的表有很是多的列，那么这块要提早注意下是否是能够拆分出去。

GC can not work

GC 的数据包括两部分，一部分是 DML 和 DDL ，DDL 的 GC 的对象信息包含在mysql.gc_delete_range 和 mysql.gc_delete_range_done ，分别记录的是待 GC 的对象以及已经 GC 的对象。mysql.gc_delete_range_done 表里面没有数据不表明 GC 异常。

官方建议更换规则：

sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d]))

TiDB or 条件优化

在 TiDB 中，以下查询是不能用到索引的：

select * from manual_domain where host_md5  = '55fbea39965484a61xxxxxxxxxx'  or domain_md5 = '55fbea39965484a61xxxxxxxxxx';

MySQL 中用到了 index_merge，TiDB 计划 4.0 支持，能够先用 union all 来处理这种 a or b。

Coprocessor CPU 消耗过大

业务反馈查询变慢，发现是另一个业务全表扫 insert into select 导数据致使的。

去 CPU 占用率高的这台机器上搜索对应的 log，关键字 slow，发现以下状况：

[2019/09/18 10:04:37.339 +08:00] [INFO] [tracker.rs:150] [slow-query] [internal_key_skipped_count=46649] [internal_delete_skipped_count=0] [block_cache_hit_count=1596] [block_read_count=9] [block_read_byte=31933] [scan_first_range="Some(start: 7480000000000002285F72800000000021E9BD end: 7480000000000002285F72800000000024199A)"] [scan_ranges=1] [scan_iter_processed=46650] [scan_iter_ops=46652] [scan_is_desc=false] [tag=select] [table_id=552] [txn_start_ts=411244239493267464] [wait_time=2ms] [total_process_time=1.41s] [peer_id=ipv4:192.168.1.248:45686] [region_id=835437]

根据 table_id 去经过 information_schema.tables 表查一下，能够经过上述方式来定位到是哪张表致使的问题。

TiDB enum 致使的性能问题

1. enum 在 TiDB 3.0.2 进行 where 条件查找是，发现不能下推到 TiKV。官方说4.0GA 修复。临时办法是修改到其余类型。

2. enum modify 为 tinyint 发现内容出现变化，本来的’'变成了 default 值，‘1’ 变成了 2，经测试 varchar 正常，所以不要尝试去变动 DM 备份出来的 schema 文件来实现表结构变动，应该从上游 MySQL 解决。

分区表元数据没法获取

没有视图能够查询当前已建分区信息。在 TiDB 中目前没有视图支持查询分区表已建分区信息，那么用户那边没有办法直观的判断当前已建的分区，以及当前是否须要及时的添加新分区。目前已转化为 PRM 产品需求，相信新版本不旧会实现。

分区表 - 部分分区 - limit 未下推

分区表出现 limit 未下推的现象，表 content_info_p 其中只有分区 p201911 有数据。该问题已在 3.0.6 版本修复。

mysql.tidb 表权限异常

使用 use db_name 或者 mysql 客户端指定 DB name 后，能够对该表进行查询或更新操做。计划 3.1 版本修复。

事物的限制

单个事物的 SQL statement 不超过 5000（stmt-count-limit 参数可调）；

每一个键值对不超过 6M；

键值对的总数不超过 300000；

键值对的总大小不超过 100M;

注：键值对是指一张表里有 2 个索引，那么一共就是数值 +2 个索引，总共 3 个键值对，那么每一个键值对的老是不能超过 30万/3 = 10万。

一行数据会映射为一个 KV entry，每多一个索引，也会增长一个 KV entry，因此这个限制反映在 SQL 层面是：总的行数 *(1 + 索引个数) < 30w。

官方提供内部 batch 的方法，来绕过大事务的限制，分别由三个参数来控制：

tidb_batch_insert

tidb_batch_delete

tidb_dml_batch_size

写热点的处理

若是能够去掉 MySQL 自增主键，就能够经过建表时指定 SHARD_ROW_ID_BITS、PRE_SPLIT_REGION 来实现预切分，避免单调自增引起的只往某个 KV 上写数据引发的热点问题。详情可参考官网 TiDB 专用系统变量和语法中 SHARD_ROW_ID_BITS 的介绍。

TiDB 监控和 DM 监控 Ansible 部署数据冲突

这块能够经过将 TiDB 和 DM 监控部署到不一样的机器上来绕过解决，不然就会出现经过 Ansible 安装后，ansible-playbook rolling_update_monitor.yml --tags=prometheus 时，二者只有一个是正常的。

磁盘已使用不建议超过 50%

数据量太多 LSM 过大， compaction 成本会很高，而且内存命中率降低，同时单机恢复时间很长，50% 左右最好，使用率过高，若是忽然写入爆增，region 来不及调度会写满磁盘，有风险。所以建议 SSD 不要使用超过 2T 的，采用更多的机器会有更好的性能。

Mydumper 致使的内存和网卡打满

在使用 Mydumper 备份大时，会打满 TiDB 网卡，同时会消耗 TiDB、TiKV 更多的内存。

【TiDB ERR】[emergency]TiDB_schema_error:192.168.1.1:10080,[add_dba_mysql]【360】

【TiDB ERR】[critical]NODE_memory_used_more_than_80%:192.168.1.2:9100,[add_dba_mysql]【360】

去抓取慢日志会看到以下内容：

grep Query_time tidb_slow_query-2019-12-24T04-53-14.111.log|awk -F : '$2>10'

# Time: 2019-12-24T03:18:49.685904971+08:00

# Txn_start_ts: 413433784152621060

# User: backup@192.168.1.3

# Conn_ID: 4803611

# Query_time: 4002.295099802

SELECT /*!40001 SQL_NO_CACHE */ * FROM `360`.`t_d` ;

期待后续的版本物理备份，逻辑备份看起来目前是能够备份，但会比较消耗资源，同时恢复时间也会更久。

展望

从 TiDB 2.x 开始咱们就已经开始进行测试了，最终选择的版本是 3.0.2，后续升级到 3.0.5。上述文章总结和一些案例但愿可以帮助到已使用或打算使用 TiDB 的朋友。

360 云平台 DBA 团队也计划将 TiDB 推上 360 HULK 云平台，为 360 集团更多的业务线提供丰富多彩和稳定可靠的数据库服务。在这里首先要感谢 PingCAP 同窗及时的技术支持，帮助咱们尽快的解决了一些技术问题。同时，我本身也通读完了 TiDB 的官方手册。从 Ansible 部署、二进制部署、升级、DM、Lighting、Pump、Drainer、调优、排障、迁移、备份，这一路打怪下来，切身感觉到了 TiDB 愈来愈好的过程。

我相信将来随着 3.1 和 4.0 版本的推出，有更多人加入使用 TiDB 的这个队伍中来。从业务给咱们的反馈也是对 TiDB 的使用状况表示满意，咱们相信，TiDB 会在你们共同的努力下，愈来愈好。