1、 GC 是指针对drop tenant这种操作做回收处理吗？ 官网上没有搜到相关机制介绍
2、
（1）undo_retention=0 时未开启多版本，也就是说只保留当前最新版本，那么历史版本的清理策略是什么，应该不会实时清理旧数据吧？ 按照lsm tree机制应该也不是新版本直接覆盖旧版本吧？
（2）undo_retention 是否和前面的GC机制有关？ 比如compact时超过undo_retention时间范围的数据会被丢弃？
(3) 文档中提到 ‘ 租户开启多版本转储后，大版本合并会保留对应的增量转储文件，但 Major SSTable 中不会存放多版本数据’ 如果最后一层sstable没有多版本数据，那多版本的数据存在哪里了呢？
3、这里的日志流删除 指的是什么
1、GC在数据库中有很多方面，你截的这两个图应该不是一个概念，第一个截图是指这个后台线程会将日志流状态为need gc的日志流GC，第二个截图是指你删除租户这个schema变更时延迟执行的。当然删除租户之后会对应的删除日志流，这时候会和gccollector配合起来
2、lsm树有冻结转储合并操作，这个undo retention为0表示不转储，直接合并到major，就算是这样也不是直接覆盖旧数据，因为至少还有一层memtable；和前面的gc不是一套机制；lsm tree两层，一层memtable（包括冻结），一层major层，这两层属于lsm tree级别的多版本，其中memtable内部数据也会有多版本。可以去了解一下lsm树以及ob的lsm数
3、日志流删除会首先锁住ls，等待只读事务结束，按顺序设置ls状态为offline、stop，等待迁移任务结束，写remove log到slog，删除该日志流所有tablet数据，删除tx table数据，删除同步删除__all_ls_status表中该日志流的数据，等等。
1、‘志流状态为need gc的日志流GC’ 这个是一个什么样的状态？ 和undo_retention有关系吗？
2、不是lsm的问题，按文档描述‘租户开启多版本转储后，大版本合并会保留对应的增量转储文件，但 Major SSTable 中不会存放多版本数据’ 开启undo_retention后 历史版本数据放在哪里了？
3、 什么情况下会出现 删除日志流？
日志流状态为need gc是将要删除的状态，gc collector检测到这个状态之后会执行真正的删除动作，和undo retention没有关系
第二个问题，undo retention开启之后，ob lsm架构的L0和L1，也就是memtable（一直会有多版本），min sstable、minor sstable都会存放多版本数据
第三个问题，删除租户，或者分区变更迁移的时候
感谢！
GC是什么？按照前面说的2种GC 具体的原理 作用是什么？
多版本的保留时间是undo_retention控制吧？ min/minor sstable 一直保留多版本的话 有没有设置2层大小的上限？
