v4.0.0-rc.1升级到v4.0.0-rc.2，tiflash无法正常开启

🪐 TiDB 技术问题
,
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：Release Version: v4.0.0-rc.2

目前的集群结构

image
image1035×238 5.53 KB

各个节点配置：
image
image775×163 4.17 KB

  • 【问题描述】：
    在v4.0.0-rc.1升级到v4.0.0-rc.2后，tiflash不可用，占用大量内存，导致tiflash无法正常开启。v4.0.0-rc.1中tiflash是可以正常使用的

image
image833×176 5.74 KB

服务器内存

image

问题：怎样配置tiflash的使用内存限制？

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

麻烦上传下tiflash.log 日志，多谢

3

链接: https://pan.baidu.com/s/15SQT2K0M0GMvtNhHY8pwpA 提取码: a8h6 升级时间大约在2020/5/19 16:00之后

4

还遇到一个问题，当tiflash宕机的时候，优化器不能感知tiflash宕机。执行计划依然使用tiflash存储引擎，导致sql不能出结果。并且sql语句要执行很长时间，才返回tikv server timeout。

image
image695×411 3.45 KB

5 
  1.正在查看日志，多谢
  1. 新的问题，麻烦开个新帖，这个帖子集中开无法启动的问题，不要混在一起，多谢。
6

好的 谢谢，已新开一个帖子

7

能够提供下当前有多少个表创建了tiflash副本，每个表的行数分别有多少么？

select * from information_schema.tiflash_replica;

可以暂时通过指定下面的变量，从 tikv 统计出行数

set @@session.tidb_isolation_read_engines = 'tikv';
select count(*) from table_name;
8

image

行数：
t_min1k ：18.2亿
t_min5k： 6.2亿
t_dayk：1.6千万

9

麻烦再提供下tiflash磁盘空间的占用哈

du -sh /data/data/tiflash-9000/*

10

image

11

你好，请提供下包含升级 v4.0.0-rc.2 前后内存使用的情况：

  • 打开 grafana 页面，左上角选择打开 Node_exporter
  • 左上方 “host” 选择 tiflash 所部署的节点
  • 右上角选择时间段，保证包含升级前、后的时间段
  • 展开 “memory” tab，截图一下包含 “memory”, “Distribution” 两个 panel 的图片，上传一下
12

image
image1809×400 49.1 KB

13

你好，
先mv tiflash-9000/log tiflash-9000/log-old; mkdir tiflash-9000/log 新建一个 log 文件夹，
然后编辑 tiflash-9000/config/tiflash.toml，把其中的 [logger] level 改为 “trace”
拉起 tiflash 进程，错误退出后再打包上传下日志文件夹

多谢

14

tiflshlog.tar (363.2 KB)

15 
2020.05.20 14:06:52.753680 [ 23 ] <Information> Region: [region 43737] useless admin command CompactLog at [term: 392, index: 2006]

这边看到最后一行是这样，但是没有看到重启或者类似 “Received termination signal.”。确认下日志是否完整包括了tiflash进程被杀的时间？

另外可以通过下面的命令确认下被系统 kill 的时间和原因

grep -C 20 -i 'killed process' /var/log/messages
16

image
image924×553 10.1 KB

17

日志最后一行就是这个

image
image903×169 3.43 KB

开启tiflash之后。输入一些类似ls的系统命令也会报错
[root@10-205-203-56 log]# top
-bash: fork: Cannot allocate memory
[root@10-205-203-56 log]#

18

暂时无法定位到详细原因，我们内部会尝试复现、修复这个问题。

您这边建议先强制下线这个 TiFlash 节点，然后更换为在 128G 内存的机器上部署 TiFlash 后，再从 TiKV 同步数据至 TiFlash 进行测试。

强制下线无法正常启动的 TiFlash 节点的步骤：

  1. 先确认 TiFlash 进程已停止，不在反复重启的状态
  2. 对所有添加了 TiFlash 副本的表执行
alter table <db-name>.<table-name> set tiflash replica 0;
  1. 在 pd-ctl 中输入 store 命令，查看该 TiFlash 节点对应的 store id （“labels"属性中含"key”: “engine”,“value”: “tiflash”）
  2. 在 pd-ctl 中输入 store delete <store_id>，其中 <store_id> 为第3步查到的该 TiFlash 节点对应的 store id。
  3. 手动查询并清理PD实例中所有与 TiFlash 相关的数据同步规则。如：
    查询所有同步规则
    curl http://<pd_ip>:<pd_port>/pd/api/v1/config/rules/group/tiflash
    删除所有与 TiFlash 相关的同步规则。以 “id” 为 “table-45-r” 的规则为例，通过以下命令可以删除该规则
    curl -v -X DELETE http://<pd_ip>:<pd_port>/pd/api/v1/config/rule/tiflash/table-45-r
  4. 从 PD 处强制下线此 TiFlash 节点
    curl -X POST 'http://<pd_ip>:<pd_port>/pd/api/v1/store/{store_id}/state?state=Tombstone'，其中 <store_id> 为第3步查到的 TiFlash 节点的 stroe id
  5. 使用 tiup scale in 命令缩容 TiFlash 节点，参考 4.3 关闭 TiFlash 进程
  6. 手动确认 tiup 部署的 TiFlash 目录已删除
  7. 重新使用 tiup scale out 命令扩容 TiFlash 节点，参考 使用 TiUP 扩容缩容 TiDB 集群
19
  1. 麻烦先按照上面的步骤操作下，另外测试也尽量留足内存给tiflash。麻烦了，多谢

TiFlash 单独部署模式

  • 最低配置：32 VCore, 64 GB RAM, 1 SSD + n HDD
  • 推荐配置：48 VCore, 128 GB RAM, 1 NVMe SSD + n SSD

部署机器不限，最少一台即可。单台机器可以使用多盘，但不推荐单机多实例部署。

推荐用一个 SSD 盘来缓冲 TiKV 同步数据的实时写入，该盘性能不低于 TiKV 所使用的硬盘，建议是性能更好的 NVMe SSD。该 SSD 盘容量建议不小于总容量的 10%，否则它可能成为这个节点的能承载的数据量的瓶颈。而其他硬盘，可以选择部署多块 HDD 或者普通 SSD，当然更好的硬盘会带来更好的性能。

TiFlash 支持多盘部署，所以无需使用 RAID