别看tidb-server的日志，tidb集群的启动顺序是pd→tikv→tidb-server，现在你的tikv都起不来，先排查tikv不能启动的原因

查看集群状态，不需要ssh登录到其他主机上的，是调用的各个节点的api获取的状态，但是关停需要执行系统命令，所以要ssh登录

tidb上先试一下 SELECT * FROM sys_org LIMIT 1; 能不能查询

每个tikv会把自己的备份放到各自节点上，一般建议指向一个共享存储nfs/s3之类的，如果是本地目录就要汇总一下。

2个副本和1个副本没区别的，都是挂一个直接废。。。。 至于在线改副本数量，主要影响的是tikv的io，pdctl改下pd store limit ，改小一点，应该会慢一点删除副本，影响没那么大

检查 Region 分布 ：通过 SHOW TABLE REGIONS 查看目标表的 Region 分布情况，确认是否存在 Region 集中在单个 TiKV 节点的现象

现在在恶补大模型相关的知识，确实以前引以为傲的经验现在越来越变得微不足道了。。。

你现在可以在tidb和pd机器上测试访问通tikv机房的ipv6地址吗？ping和telnet，如果可以的话，单独配置tikv的host为ipv6也没问题

tidb-server，pd，tikv，全部都可以配置成ipv6

确实，我也是仔细读了好几遍。。。

应该是你对这里的schema理解有点问题，这里的shema相同是指的表的 逻辑表结构、索引等元数据完全一致，不是指他们所属于的schema一致。

TiDB集群是6.1.4，BR工具是6.2.0之后的版本，也可以实现pitr的功能，但是不保证不出现其他的问题。。。

直接所有节点的host地址配置成ipv6地址不行吗？

FLUSH PRIVILEGES; 执行了？ 试一下 UPDATE mysql.user SET account_locked = ‘Y’ WHERE user = ‘username’ AND host = ‘host’; FLUSH PRIVILEGES;也不行吗？

集群拓扑结构发下呢，你这tikv已经oom了，内存释放了，总的内存还有9G被占用？

看着日志级别都是warn，应该是不影响使用的，导出也成功了，你检查下生成的文件，如果只是"error reading server preface: http2: frame too large"”这个报错的话，尝试调整tikv的如下参数 max-grpc-recv-msg-size

那不是有个保存草稿，没事点一下啊，不过也确实可以加个每隔30秒自动保存的。。。。 不过一般发文章不是现在本地编辑完了，只在网页上修改格式的嘛。。直接在网页上写我没试过。。。

【聊聊你的 TiDB SQL 使用过程中遇到的问题】 建表不合理使用auto_increment做主键导致写热点，json字段查询慢，漏建索引 【你的 SQL 优化实践经验】 重建表改成auto_random，增加虚拟列然后针对虚拟列建索引，新加索引 【如果有线上 Meetup，你想听关于 SQL 优化的什么内容】 tidb的cbo规则解析，以及每个版本针对cbo的优化和改进

应该部署不上去，因为端口占用掉了，建议另外指定一个地址