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 有定期任务,负责:
该组件的日志输出为 tiflash_cluster_manager.log。如果集群中存在多个 TiFlash,会通过 PD 内置的 etcd 选出一个来负责上述任务。通过日志排查时需要拿到该时间段内负责该工作的节点,或者拿全部 TiFlash 节点的相关日志。
PD 的行为:接收到 placement-rules 后,PD 会:
TiKV 的行为:
对于已经有 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 操作:
不同阶段出现问题时排查的方向(举例)
执行 `alter tableset tiflash replica` 时卡住
通常来说,这句 DDL 操作仅修改 TiDB 中的元信息,执行时不会阻塞太久。如果出现执行此语句卡住的问题,可以看是否有其他 DDL 操作 block 了该语句的执行(比如在同一个表上是否存在 add index 操作)。更多地可以参考其他 TiDB 中 DDL 卡住的经验 [FAQ] DDL 卡住排查经验 - TiDB 常见 FAQ。
副本数修改成功,但是 progress 一直为零,或者 progress 有进展,但是很 “慢”
对已经有 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
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。