那肯定，flashback table 本质是把表的 drop、truncate 这两个 ddl 操作恢复，你的误操作指 insert、update、delete 这样的 dml ？但实际应用场景，这类 dml 误操作很少吧，如果实在想要恢复这种 dml 操作，就在 gc 时间内 使用 使用 AS OF TIMESTAMP 语法读取历史数据 | PingCAP 文档中心 这个功能，去读历史数据呗

无疑是索引观测以及 tiproxy

支持的，前提是使用 tidb on k8s 的部署方式，使用 tidb operator

建议 在导出之前就改表名，导出之后再改回去 导入之后改表名，改个表名而已，多写一个脚本的事情

你flashback cluster 肯定啊，你针对 t1 表，你就针对 t1 表flashback 呀，flashback 有table、database、cluster 三个维度

你用 ctl 改吧，那是实时生效的，很少这样 reload pd 的方式去改，而且，这个版本默认参数就是这个值，我前面也说了，他只是没恢复

昨晚忘记回你了，被别的事儿占据了。 空region一般就是数据库删数，接着数据库 gc 之后出现的，如果空 region 的数量长时间没降低，大概率是因为某个操作，常见的有br导入数据，导致 pd 的调度暂停而没有恢复，这时候可以通过 pdctl 去查看 pd 关于调度的几个参数，我看你前面回帖里面也查了，通过 tiup ctl:{tidb_version} pd --pd http://{pd_ip:port} -i 进入 pdctl 的控制台，然后数据 config show 就能看到 pd 的一些参数了，然后通过 config set {variable_name} {value} …

54、56、57、58 这四台机器的 kv oom 重启次数多吗？机器配置啥样的

呃，别这么写96636764160吧，你设定90GB，你就写 90GB，这个配置默认单位我记得不是 bit，下面的 raftstore.capacity 也是，都改一下，带上单位，reload 下，难改你参数没生效

你这个不是今天重启的吗？

不会吧，tikv.log ，这个文件没了吗？

再就是看看 tikv 的启动日志，日志里面关于重启的 welcome to tikv 那行的前后 20条，我感觉你这个参数没生效，是写在 tiup 配置文件里面配置的吗？

60、61这两台机器上除了部署 tidb 、 tikv 就没部署其余的是吧。能看看这两个机器的配置吗？

能看一下 tikv OOM 时间点前后的日志吗？你是设置了block-cache-size参数的，为啥你的 tikv 还能用到 110G左右的内存，能检查下参数设置的值吗？

这个是你服务器下载到一半断开连接了吧，看一下，你服务器网络确实比较慢

确实，可以提 pr 去改了

能看一下这两台机器对应的 grafana的监控图吗？就 tidb、tikv mem usage的那个面板。为什么你这个挂的会是 tikv，混合部署，你限制了 kv 的内存之后，一般不会超过这个 范围，要挂也是挂 tidb

tikv OOM 还是 tidb OOM？能看下集群部署架构吗？

一般能限制住，能看看你的部署架构吗？