作者： 18515065291 原文来源：https://tidb.net/blog/a898b21e

TiFlash 运维漫谈

  2020-10-25  刘春雷

1、前言

自 TiDB 4.0 版本问世之前，TiFlash 就被大家高度关注。TiFlash 是什么？他能做什么？他如何使用？他运维起来麻烦么？他有什么坑？他能真正解决困扰 MySQL DBA 的 分析型业务无法支持 的问题么？本篇文章更偏向实际使用、运维体验，原理请移步官网~

58 这边，自 4.0.0-rc.2 版本就开始调研 TiFlash，到目前，大约使用 5 个月 左右了， 7 套 线上集群在使用 TiFlash 解决分析型 SQL 的效率问题。

2、TiFlash 简介

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

整体架构

3、部署及使用

推荐：

使用更好性能的磁盘、大内存，多核 CPU 的机器进行部署, 官方：32 VCore 64 GB 2TB (nvme ssd) * 1 ，58 这边大致机器为 40 核、128G 内存、SSD RAID5 或闪存卡机器。

3.1、部署流程

使用 tiup 工具部署，分为初始化部署、已经存在集群部署 TiFlash，区别不大，都是要写好 yaml 文件即可。

【1、集群配置】：

需要将配置模板中 replication.enable-placement-rules 设置为 true，以开启 PD 的 Placement Rules 功能。，或使用 pd-ctl，执行 config set enable-placement-rules true 。或者 tiup 也支持，tiup ctl pd -u

【2、配置文件】：

tiflash_servers:

• host: 10.0.1.11

• data_dir: /tidb-data/tiflash-9000

• deploy_dir: /tidb-deploy/tiflash-9000

• ssh_port: 22

• tcp_port: 9000

• http_port: 8123

• flash_service_port: 3930

• flash_proxy_port: 20170

• flash_proxy_status_port: 20292

• metrics_port: 8234

• deploy_dir: /tidb-deploy/tiflash-9000

• config:

• logger.level: “info”

• learner_config:

• log-level: “info”

• host: 10.0.1.12

• host: 10.0.1.13

【3、执行部署】

新部署集群包括 TiFlash 节点：

tiup cluster deploy tidb-test v4.0.6 ./topology.yaml

扩容 TiFlash 节点：

tiup cluster scale-out scale-out.yaml

【4、检查节点状态】

tiup cluster display cluster-name

3.2、使用

【表添加至 TiFlash】：

使用上很简单，只需要知道将哪些表同时放到列存 TiFlash 里面，执行个 SQL 就行了~

• ALTER TABLE table_name SET TIFLASH REPLICA count

• count 表示副本数，0 表示删除

【查看】：

SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ‘<db_name>’ and TABLE_NAME = ‘<table_name>’;

• AVAILABLE 字段表示该表的 TiFlash 副本是否可用。1 代表可用，0 代表不可用。副本状态为可用之后就不再改变，如果通过 DDL 命令修改副本数则会重新计算同步进度。

• PROGRESS 字段代表同步进度，在 0.0~1.0 之间，1 代表至少 1 个副本已经完成同步。

【TiDB 读取使用】：

TiDB 提供三种读取 TiFlash 副本的方式。如果添加了 TiFlash 副本，而没有做任何 engine 的配置，则默认使用 CBO 方式。 会话级别，即 SESSION 级别

【如何确认使用】：

explain 查看 SQL 执行计划，看 task 字段里面是否有 tiflash，有 表示该任务会发送至 TiFlash 进行处理 。例如：

【engine 隔离】：

适用于某些特殊场景：

• 明确使用其他 engine 效率比较好，如使用 TiKV 效率更好

• 或者进行影响隔离，例如某些大批量数据的查询，可以单独走 TiFlash，减少对线上读写影响

set session tidb_isolation_read_engines = “逗号分隔的 engine list”;

【支持计算下推】：

TiFlash 支持谓词、聚合下推计算以及表连接，下推的计算可以帮助 TiDB 进行分布式加速。暂不支持的计算类型是 Full Outer Join 和 DISTINCT COUNT，会在后续版本逐步优化

set session tidb_opt_broadcast_join=1

其他下推优化 ：

set @@tidb_opt_agg_push_down=1;

set @@tidb_opt_distinct_agg_push_down=1;

4、使用经验

4.1、元信息部分

因 TiDB 多端口的特性，混合部署的话，推荐集群间端口间隔的多一些，例如间隔 50 个端口，这样会减少端口冲突的情况。且 TiFlash 想比较其他角色，端口比较多，6 个左右。这样就需要单独一张角色表，记录 TiFlash 的基本信息，与 TiDB 其他实例表相关联。

4.2、有哪些坑

• 问题 1 ： 对资源消耗很大，比 tikv 节点大， 某集群部署 tiflash 后，添加写入特别频繁的表至 TiFlash，且几乎没有读 TiFlash 的情况，TiFlash 节点的 CPU 使用率 100%，推荐大家 使用多核 CPU 的机器 。

• 问题 2：无法限制内存 ， 这个写入特别频繁的表的 tiflash 异常重启多次，排查为内存吃满 oom 了，此机器的内存 128G，直接使用完 oom…启动占用大内存的问题，已经提给官方，官方在修复 。

【排查系统日志如下】

ep 28 16:35:42 10.0.0.1 kernel: [34135946.096974] Out of memory: Kill process 506925 (tiflash) score 896 or sacrifice child

【监控情况如下】

【内存使用情况如下】

【tiup 状态】

因重启检查超时，TiUP cluster display 结果显示变成 Down，或者 Disconnected

• 问题 3 ： 修改 pd 节点 ，切换后，TiFlash 的 PD 信息不同步 …不同步…需要手动修改 TiFlash 的配置 tiflash.toml

日志报错如下：

需要改 tiflash.toml 里面 pd 信息，改成新的

​[raft]

pd_addr = “10.0.0.1:100,10.0.0.2:100,10.0.0.3:100”

• 问题 4： 不能正常开启 TiFlash 的话，也不能正常的 scal-in 下线，需要手动清除同步规则，及强制从 pd 删除这个节点信息，参考 wiki：

docs.pingcap.com

使用 TiUP 扩容缩容 TiDB 集群

PingCAP Docs

docs.pingcap.com

使用 TiUP 扩容缩容 TiDB 集群

PingCAP Docs

5、对比 ClickHouse

面对如火如荼的 ClickHouse，TiFlash 又性能如何呢？我们进行了如下测试。

5.1、性能对比

【机器信息】

内存： 192G

CPU： 20*2 Intel® Xeon® Silver 4114 CPU @ 2.20GHz

磁盘 ：3*1.8T SSD RAID5

部署 ：单机单实例部署

版本： ClickHouse 版本 20.3.8.53 ，TiFlash： 4.0.0-rc

【 ClickHouse 查询如下 】：

【汇总对比如下】：

【差异原因】：

tiflash 因为需要支持 update，所以需要额外读取三列：handle (int64), version(uint64), del_mark(uint8)

clickHouse 只需要 scan，但是 tiflash 需要把数据做一次全局排序 + mvcc 过滤，这些是固定成本。

5.2、场景对比

clickhouse 目前大致的使用场景为：

• 作为 MySQL 的从库使用，这样受限于 MySQL 的集群大小及读写效率的考虑，表可能不大，百 G 左右

• 独立部署集群，大小不限制，专注于高效分析

TiDB 目前在 58 主要为解决 MySQL 的痛点问题：例如单表超 100G，推荐迁移至 TiDB。或者新业务，体量大，流量高的场景。

TiFlash 可以依托 TiDB 使用，使用方便，与 TiKV 一起，可以支持更多的场景，所以使用的就更广泛。

大致场景对比如下：

6、TiFlash 的日常使用心得

对于 58 的 50 多套集群，到底哪套集群？哪些表？哪些 SQL 需要使用 TiFlash 来优化呢？这是一个很大的难题！真的很大~

1. 首先需要 DBA 了解所有集群的业务，了解所有集群的常见慢 SQL、高频 SQL 情况，想想 50 套集群、想想每天大致 50 多亿次访问的 TiDB 业务，这对于 DBA 就要求很高了。

2. 因为磁盘的限制，不能所有的表都添加至 TiFlash 里面，只能找在查询上可以使用 TiFlash 优化的表，这点很难！需要逐个测试，逐个…

3. 58 的集群里面，有数仓业务，有报表业务，有信安的实时写入与分析业务。这几种是大致可以确定使用 TiFlash 优化的，然后我们需要详细分析测试…

4. 然后我们要查看这几套集群的慢 SQL、高频 SQL，然后将表添加至 TiFlash 里面，逐条 explain 来查看执行计划，然后确定哪些是可以走 TiFlash 的，这个同步过程也很漫长，表越大越长，有同步 1 周多的…这个测试的周期就被拉的很长~ 很长~

5. 然鹅现实有时候很骨感，很多 SQL，explain 查看执行计划是不能被 TiFlash 优化的，有些联合索引添加的很好，查询完全匹配的时候，就直接走 TiKV 的索引扫描了，只有很少部分的 SQL 可以通过 TiFlash 优化…

6. 监控上，查看 TiFlash-Summary 的 Request QPS 监控图，也是不尽人意，很少的 SQL。

7. 目前上的几套集群里面，TiFlash 优化好的 SQL 有一些，例如原 SQL 19.9s，优化后 0.48s，业务非常开心~

8. 当然线上还是有很多的 SQL 可以通过 TiFlash 优化的，只是这个需要 DBA 耗费很大的人力去测试、确定

总之：

• TiFlash 能很好的优化一些分析型的 SQL

• TiFlash 能很好的使用，需要 DBA 付出很大的精力，较长的时间~

• TiFlash 还存在很多可以优化的地方，例如

• 添加内存限制

• 解决 TiFlash 重启慢的问题

• TiFlash 机器资源使用过高的问题

• 支持更多的查询情况优化

• SQL 能否给出智能的建议：使用 TiFlash 优化~，这样来减少 DBA 的工作量

• 性能上的提升

希望 TiFlash 使用的越来越简单，问题越来越少，效率越来越高~