关于数据库:TiDB-HTAP-上手指南丨添加-TiFlash-副本的工作原理

TiFlash 是 TiDB HTAP 状态的要害组件，它是 TiKV 的列存扩大，在提供了良好的隔离性的同时，也兼顾了强一致性。列存正本通过 Raft Learner 协定异步复制，然而在读取的时候通过 Raft 校对索引配合 MVCC 的形式取得 Snapshot Isolation 的一致性隔离级别。这个架构很好地解决了 HTAP 场景的隔离性以及列存同步的问题。

应用 TiFlash 前，须要给表增加 TiFlash 正本。不少用户反馈增加 TiFlash 正本的时候呈现问题。TiFlash 正本始终处于不可用状态官网文档总结了一些简略的问题排查。

这篇文章将介绍目前版本（目前所有 release 的 4.x, 5.x 版本）下给 TiDB 中的表增加 TiFlash 正本的工作原理，次要供 DBA 同学们排查相干的问题时，能够从中参考先从哪些方面收集信息及尝试解决。

基本概念

在 PD 的视角里，TiFlash 实例与 TiKV 实例相似，都是一个 store，只是 TiFlash 的 store 会带有“key=engine, value=TiFlash”的一个 label。增加 TiFlash 正本后，PD 把 region 调度到 TiFlash，并让其中的 region 始终只以 learner 的模式存在，依赖的是 Placement Rules 性能。

TiFlash 实例中蕴含有一个批改版本的 TiKV 代码，次要负责与 TiKV 协同解决 Raft 层的操作，其输入日志与 TiKV 基本一致。TiUP 部署时，其日志会输入到 tiflash_tikv.log。

TiFlash 实例会定期启动一个子过程来解决与 TiFlash 正本增加、删除相干的操作。如果在过程列表中偶然看到一个名为 tiflash_cluster_manager 的不常驻过程（在官网中称为“pd buddy”），属于失常状况。其日志会输入到 tiflash_cluster_manager.log。

TiFlash 外部组件架构图

增加 TiFlash 正本各阶段集群中组件的工作

增加 TiFlash 正本的时序图

执行正本数批改 DDL

在 TiDB 中执行 alter tableset tiflash replica 时，这条语句作为 DDL 语句执行。

从 progress 0.0 到 1.0 的同步过程中

TiDB 提供 http 接口，其余组件能够通过此接口查问哪些表存在 TiFlash 正本：curl http://:/tiflash/replica。
TiFlash 有定期工作，负责：

1. 从 TiDB 的 tiflash/replica 接口拉取哪些表 / 分区有 TiFlash 正本。对于未 available 的表，如果表在 PD 上没有相应的 Placement Rules，该工作会负责设立相应的 rule，key range 为 [t__r, t__)。
2. 对于未 available 的表，该工作会从 PD 拉取 key range 对应的 region_id，以及在线的所有 TiFlash store 中有多少曾经同步的 region_id。
3. 以 TiFlash store 中去重后的 region_id 个数 PD 中 region_id 个数，通过给 tiflash/replica 接口发 POST 申请的形式更新同步进度 progress。
4. 如果 PD 中存在 placement-rules 但 tiflash/replica 中不存在相应的 table_id，阐明该表 / 分区曾经被 DROP 而且曾经过了 GC 工夫，会到 PD 中移除相应的 rule。

该组件的日志输入为 tiflash_cluster_manager.log。如果集群中存在多个 TiFlash，会通过 PD 内置的 etcd 选出一个来负责上述工作。通过日志排查时须要拿到该时间段内负责该工作的节点，或者拿全副 TiFlash 节点的相干日志。
PD 的行为：接管到 placement-rules 后，PD 会：

1. 先对 Region 进行切分，确保 Region 的边界不会逾越 表数据 及 索引（因为 TiFlash 只同步表数据局部）
2. 对 Region 的 Leader 下发 AddLearner 到 TiFlash store 的调度

TiKV 的行为：

1. TiKV 中 Region 的 Leader 承受并执行 PD 的 AddLearner 命令
2. Region Leader 以 Snapshot 模式把 Region 数据发送到 TiFlash 的 Region peer

对于曾经有 TiFlash 正本的分区表进行 Add partition 的过程

TiDB 对曾经有 TiFlash 正本的分区表进行 Add partition 时，会在生成 partition 后（但对用户不可见）block 并期待。直到 TiFlash 上报该 partition 对应的 partition_id 曾经 available 后，DDL 才执行实现。（具体内容可参考 TiDB 相干 PR）
对于 TiFlash 而言，给分区表增加一个 partition 与增加一个一般表是相似的操作，能够参考上文的流程。不同的是在此状况下，会额定在 PD 增加 accelerate-schedule 的操作，晋升分区表 key range 相干 Region 的调度优先级，以冀望在集群忙碌的状况下，缩短分区表的 available 速度，缩小 DDL block 的工夫。
为什么须要 block 分区表的 Add partition 操作：

• 如果不 block Add partition 的 DDL 操作，在用户执行查问语句时 (比方 count(*) )，如果查问抉择了从 TiFlash 读，然而新 partition 上的 region 还没有建设起 TiFlash 正本，此时会导致用户的查问因为多数的 region 而失败。体现进去为用户在执行 Add partition 时，查问该表不稳固，容易失败。
• 为了防止造成查问的不稳固，block 分区表的 Add partition 操作，待新建分区的 Region 建设完 TiFlash 正本 ready 后才容许读到该分区。

不同阶段呈现问题时排查的方向（举例）

执行 alter tableset tiflash replica 时卡住

通常来说，这句 DDL 操作仅批改 TiDB 中的元信息，执行时不会阻塞太久。如果呈现执行此语句卡住的问题，能够看是否有其余 DDL 操作 block 了该语句的执行（比方在同一个表上是否存在 add index 操作）。更多地能够参考其余 TiDB 中 DDL 卡住的教训 [FAQ] DDL 卡住排查教训 – TiDB 常见 FAQ。
正本数批改胜利，然而 progress 始终为零，或者 progress 有停顿，然而很“慢”

• 先依据 TiFlash 正本始终处于不可用状态确认下根本的问题
• 上述排查无误的状况下，先查看 tiflash_cluster_manager.log 的日志。看是否与 TiDB 或 PD 连贯出现异常，如果有异样，先确认是相干组件的 API 查问超时 (curl http://:10080/tiflash/replica，见 TiDB 与 TiFlash 同步接口）还是网络连通性有问题。
• 再确认呈现问题的表是否有创立 placement-rule（tiflash_cluster_manager.log 日志中关键字“Set placement rule … table–r”），上报给 TiDB 的进度信息（id, region_count, flash_region_count）。确认 PD 上是否可能查问到相应表的 rule（参考 Placement Rules 应用文档）。
• 确认同步进度“慢”的具体表现。出问题的表，其 flash_region_count 是否很长时间”没有变动”，还是只是“变动得慢”(比方几分钟还是会涨几个 region)。

1. 如果是“没有变动”，须要排查整个工作链路上什么环节呈现问题。

TiFlash 给 PD 设 rule -> PD 给 TiKV 中的 Region leader 下发 AddLearner 调度 -> TiKV 给 TiFlash 同步 Region 数据 这个链路是否有问题，收集相干组件的日志进行排查。
能够查看 tikv、tiflash-proxy 日志中的 warn/error 信息，确认是否存在网络隔离之类的谬误。

2. 如果是“变动得慢”，能够排查 TiFlash 以后的负载、PD 的调度。

次要察看 Grafana 中的 TiFlash-Summary 看板，Raft 中“Applying snapshots Count”、“Snapshot Predecode Duration”、“Snapshot Flush Duration”几个图，反映 TiFlash 通过 ApplySnapshot 接收数据的并发度、apply 消耗的时长；以及 Storage Write Stall 中的“Write Stall Duration”是否写入太频繁，导致呈现了 Write Stall 景象；收集其余如 CPU、磁盘 IO 负载等，以及 TiFlash 的日志。
PD 相干的调度参数调整见：PD 调度参数。

对曾经有 TiFlash 正本的分区表进行 Add partition 过程中卡住

依据 PR 中的 comment，如果是因为 TiFlash 没有建设起正本而 block 住，会打印“[ddl] partition replica check failed”的日志。接下来的排查方向，大略是过后的是否有较多 Region 在建设 TiFlash 正本、TiFlash apply snapshot 的压力、PD 调度优先级是否有失效等。

附录：

一些过程中辅助排查的 API：

TiDB 中查问 TiFlash 正本、进度等

select * from information_schema.tiflash_replica

查看最近 执行 pending 的 DDL 工作

admin show ddl jobs

TiDB 中获取 TiFlash 正本音讯的 API 接口（与 TiFlash 交互的次要接口）

curl http://:/tiflash/replica

TiDB 中查问表的 Region 信息

SHOW TABLEREGIONS;

查问单个 TiFlash 节点上 table_id 对应的 Region 信息

echo “DBGInvoke dump_all_region(,true)” | curl “http://:/?query=” –data-binary @-

PD 中查问 Region 的信息

tiup ctl pd -u http://:region

PD 中查问 Placement-rules 信息

tiup ctl pd -u http://:config placement-rules show