比如br备份到本地，要恢复的话需要每个tikv节点都访问全量的备份数据，一般用s3存储或者挂载nfs方便点

show processlist或者cluster_processlist里没有可能sql已经执行完了， 慢日志里只记录IP信息。

看报错是tikv超时了，看看tikv日志是不是OOM了，另外这张表有多大，看id区间已经到7京了，不像是一个合理的值。

tidb压缩率比mysql高，不过算上3副本按2倍预留应该够了，想要算准确一点的就按方法二算算吧。

参考下这里吧 [image]

一般来说没有绝对的固定比例吧，走不走索引的影响因素很多，上面这个sql大概率是会走的，看看执行计划就知道了

官方文档有，支持 MySQL 8.0 中的大部分 JSON 函数 https://docs.pingcap.com/zh/tidb/stable/json-functions/#json-函数

没什么影响，我们这个集群每天的写入量是很大的，类似物联网那种数据会很多。之前为了做灾备集群同步数据临时改成过5天，也没有明显的延迟

我们这个集群40多TB，每天写入量不少，设置的是2天（防止周末有人误操作了周一还能快速回滚），目前没发现有明显性能问题，不过不建议设置的太大了，不然磁盘也是个问题。

3PC需要更多的通讯次数，实现比较复杂。大多数使用一致性提交协议的系统都采用二阶段提交协议。

5个节点宕机一个是没问题的，同时宕机2个就不行了

多表拆成多个drainer任务会有性能提升的，我们是一个大表单独一个任务

主键不是数字的可以用隐藏字段_tidb_rowid

没区别，现在只是语法上兼容，实际还不支持 [image]

看看是否设置了这个参数MAX_EXECUTION_TIME

tidb本身有gc，gc时间内的数据都可以恢复，不需要延迟备库 https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview/

【大家所在的行业是什么？】 能源 【所在行业对数据库容灾有哪些具体需求？】 应用级别1:1异地灾备 【目前正在采用的容灾方案是什么？】 ticdc同步

看下leader分布，是不是这个节点重启过，leader都切到其他节点了

【你想使用的数据库是什么样的】 高可用，自动拓展 【在哪些方面你会给 TiDB 投一票？易用性 or 其他？】 易用性