停机迁移就是dumpling+lightning 在线迁移就是DM或者ticdc

生产环境，为何会用7.6版本？DMR版本

应该是显式和隐式交叉插入自增列值的场景导致的吧？执行一次 alter table xx auto_increment = 0 能触发 tidbserver 重新加载 id。

大佬新鲜出炉的 https://github.com/Bowen-Tang/sql-replay https://github.com/Bowen-Tang/parse-tshark/blob/main/README.md

主要的影响官网写得很明白了。 海量 Region 集群调优最佳实践 | PingCAP 文档中心

简单说就是Paxos在某些情况下性能会高于raft，但raft更容易实现工程化，社区活跃，有更多开源贡献者。

4.0就用binlog同步吧

都可以吧，看并发。比如 load data 40个并发，如果解决热点问题来插入，那么需要更少并发。 前提是资源也没有瓶颈，nvme盘，tikv可能要解除一些限流参数。

tidb_scatter_region 默认为off，应该设置为on了。 tidb_scatter_region：该变量用于控制建表完成后是否等待预切分和打散 Region 完成后再返回结果。

6版本开始，每年2个LTS版本，年中一个，年底一个，如 6.1, 6.5 , 7.1, 7.5。 7.6版本带的很多好用的特性应该都是8.0GA，所以期待下8.1 LTS吧。

目前的基于BR日志的PITR方案RPO小于5分钟，其实GAP一般就2分钟左右，看你场景，这个又不是做备库实时恢复的方案的

楼上是对的，Systemctl 管理服务，默认配置 RestartSec=15s 自启

2个参数是且的关系，另外merge-schedule-limit默认是8已经很保守，不需要调低。

类似这样修改。 grafana重置密码_tidb grafana 密码重置-CSDN博客

DBA同学压tpcc、sysbench； 测试同学压jmeter。

每个PD日志都有啊，这已经保障丢不了。 参考： 方法1： cat /u01/tidb/deploy/pd-2379/log/pd.log | grep “init cluster id” [2024/01/17 11:49:47.039 +08:00] [INFO] [server.go:346] [“init cluster id”] [cluster-id=7212470665861270901] 方法2： tiup ctl:v6.5.7 pd -u ip:port store --jq=“.stores[] | {id: .store.id, address: .store.…

4.0少了不少诊断便捷性，也快到生命周期了。建议升级到6.5.x 吧，dashboard 有top sql 面板（top cpu），看这些问题都分分钟系列。 TiDB 版本周期支持策略 | PingCAP

表大小的计算看官网的这里。 TiDB 集群管理常见问题 | PingCAP 文档中心