存算分离架构下，在scale-in缩容tiflash节点后，S3上数据不会被清理掉

🌞 建议反馈 产品缺陷
1

当执行set tiflash replica 0后，tiflash_replica系统表及config placement-rules show都立刻看不到之前设置的表，不过tiflash副本是异步删除的，即便tiflash write_node节点状态为Tombstone后，磁盘上依旧会遗留很多数据文件。
对普通的tiflash节点在执行tiup cluster prune时候就主动删除本地的数据目录，从而达到情况tiflash数据的目的，但是在存算分离架构下S3上数据会一直存在，不会自动删除，还需要手动清理一下

2

又是韦老板的活了…

3

清理机制大概是这样：

  1. 多个 write node 中选一个 gc master 来干活
  2. gc master 定期检查是否有可以删掉的文件，被删掉或者被 compact 的规则是：1. 文件有效率低于 50%（一个文件中可能存在部分数据是已经被删掉了，其他部分还有用）；2. 文件最后一次更改时间距离现在 1hour。
  3. 文件删除有两种方法：profiles.default.remote_gc_method。1 代表依赖 S3 Object 的 tagging 和 bucket 的 lifecycle 设置来删除； 2 代表用 S3 的 ListObjects 来自行扫描删除

所以你上面把 write node 下线了，就没有 gc master 来干活了……

5 个赞
4

看来只能先写脚本自动清理了 :grinning:

5

补充两点：

  1. 如果有多个 tiflash write node，其中一个下线了。另外一个 write node 成为 gc master 后，检测到另外的 store_id 已经是 tombstone 状态，也会把旧 store_id 在 S3 上的数据删掉。
  2. 如果 profiles.default.remote_gc_method 是默认值 1，即依赖 S3 Object 的 tagging 和 bucket 的 lifecycle 设置来删除，由于 S3 lifecycle 最低过期时间是 1 天。所以在 lifecycle 机制的情况下， “被删除的文件” 至少要过 1 天才会被 S3 的 lifecycle 机制清理掉。
    由于 AWS S3 存储成本比 API 调用的成本低，所以这个机制在 AWS S3 上适用。如果是自建的 minio 等，API 调用成本不高，而又想更快清理使用空间的话，可以把 remote_gc_method 的值设置成 2 。这个机制下文件最快在 “被标记删除” 后 1 小时会被清理。

如果所有 write node 都被下线了，没有人来做 S3 里面 gc 的活。目前只能写个脚本或者在管理页面上清理了。

3 个赞
6

缩容验证了下，确实一直在删除S3上的数据

7

学习了， :+1: :+1: :+1: :+1: :+1:

8

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。