[image] 买彩票去

取事务 ts时间长就看pd leader和tidb的资源是不是被占满了，主要是cpu和网络资源。 sql Coprocessor 执行耗时，可能是有读取热点，可以看看tikv的读线程cpu高不高，均不均衡。这种大概率是优化sql来解决问题

你在哪个时间点完成了全备的？ pitr应该是只能恢复全备以后的增量数据，所以你恢复的时间点应该设置为全备以后且有增量日志的时间点

没办法这么测试

你说的整个集群突然断电的情况没测试过，不过就算出问题也有解决方法。毕竟只要三个组件：tidb，tikv，pd都正常就能正常使用。而tikv和pd都有故障恢复的方案。 我在poc的时候测试过给某个tidb和tikv断网和断电，都问题不大。

【你最想实现的 TiDB 功能需求】 针对pitr，增加监控及告警。主要是保证有异常，马上能收到反馈 【你最喜欢的 TiDB 新特性 + 理由】 向量功能，紧跟技术前沿 【你最想要周边心愿池里的哪个周边】 键盘+鼠标垫 【你考过哪些 TiDB 证书？】 所有 【你身边有多少位朋友在用 TiDB？】 10+

问了一下ai，他说 Kubernetes 1.28 中 rbac.authorization.k8s.io/v1beta1 已经被移除，所以你需要将 ClusterRole 和 ClusterRoleBinding 的 API 版本更新为 rbac.authorization.k8s.io/v1。可以试试

看报错是因为：a terminal is required to read the password ; 这个报错通常是由于使用了需要输入密码的命令（例如 sudo），但命令在没有终端的环境下运行，无法通过终端提示用户输入密码。 你应该是没有给main配置无密码 sudo。可以尝试使用tidb用户进行部署，或者给main用户配置无密码登录。类似下图： [image]

这种一般就是看启动时候的组件的日志，或者系统操作日志。根据你发的日志信息，应该就是numactl 没有安装，安装了可以不使用，没啥影响的，下面是官方的安装方法： 安装 numactl 工具 | TiDB 文档中心 (pingcap.com)

生产环境肯定是要关闭的，一开始采购机器的时候就应该采购足够的内存，而不是到最后用swap来续命。oom的本质还是sql的问题，尽量优化sql或者改写sql，就可以避免大多数oom的情况

如果leader region在offline的节点上，应该是会影响查询的

还是要先加速region的迁移，把store limit调大一些，测试集群可以调到百万级别，生产集群就调整小一点，万级就行了。删除的store，看看region count是不是在减少，如果是的话就不用管，等待region count变成0就行。如果没有减少，可能需要手动去删除对应的region

不是写的部署启动失败吗，我还以为你这是第一次启动，我说怎么有这么奇怪的问题 根据tikv报错的信息看，你好像是删除了一些region 4的数据文件。你还记得具体删除了哪些文件夹里面的日志吗

看看操作系统日志中有没有tikv的报错

看一下tiup的版本

关注慢sql的告警，及时干预吧。

其实我也不知道原理是啥，我是看其他方法都试过了，想着切换一个dashboard会不会有作用。 你先这么用着，如果下次又出现不能登录的情况，那可能pd就真的有点问题了

用display命令查看集群，然后把 Up|UI 的那个pd重启一下，这样做等于是强行把dashboard切换到其他pd上了，然后再试试能不能登录。 或者用这个命令切换也行：tiup ctl:v<CLUSTER_VERSION> pd -u http://127.0.0.1:2379 config set dashboard-address http://9.9.9.9:2379

其实是调整到合适的就行。比如多次增加store limit，直到对集群有影响了就不能增加了。我操作的时候虽然会把store limit调整的很大，但是其他参数我都调整的不大，所以一样会限制region的迁移速度，不会对集群有太大的影响