要查看所有历史sql得上审计，企业版

我猜是浏览器缓存问题

大宽表我只在数仓见过

地点：苏锡常地区 想听听大家使用tidb遇到的问题、怎么解决的。

20180 这个端口是监控用的，你看下监控是否正常？ 顺便看下/data/tidb-deploy/prometheus-8249/conf/prometheus.yml 这配置文件中的xxx:20180对不对

在 monitoring_servers 下面增加 ng_port:12020 参数： monitoring_servers: - host: 172.16.6.6 ng_port: 12020 重启 Prometheus 节点： tiup cluster reload ${cluster-name} --role prometheus 这么操作功能恢复了。

参考下

我生产遇到过一次问题，有个集群cdc大概3000+的tps（主要是插入），同步到下游kafka。 下游的kafka磁盘io满了，cdc进程就卡住了，不同步也不报错，还好我写了个监控脚本，定时监控同步时间误差，修复好下游kafka后cdc任务还是处于卡住状态。重启了cdc服务后恢复正常。

store limit 200 意思是每分钟迁移上限是200，你按照这个算下速度呗

扩容和缩容节点快不了的，我这半小时才迁移了4k个region [image]

对的，新增的节点适当调大了点 不急就等他慢慢迁移，如果你很急就等业务低谷大半夜的时候一下子全部调大，迁移完调回来。

我刚加了个节点，正在调整速度，这个可以在不影响系统的基础上适当的慢慢加 [image]

你这截图还带水印的，姓名都泄露了

TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意：不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。

tikv节点数不能少于副本数（默认3个），不然缩容会失败 另外你上面贴的备份日志显示备份失败了。 建议你先扩容一个kv节点恢复集群。

会不会是索引合并功能没开启？

我怕你去了被打出来

你敢把这个搬到ob社区发一下么？

你要是不放心，生产使用前做个压力测试，看看瓶颈在哪，有哪些可以优化调整。 每个人的系统环境都不一样，没有万能的参数调优。