自动参数调优！以后搭数据库就不用配参数了

TiDB 6.0 使用手册

这个问题已经排查解决了，原因是因为对应的 replacement 的 blackbox exporter 和 node exporter 节点挂掉了。 根本原因是之前配置了 ignore_exporter: true 然后停掉 blackbox exporter 和 node exporter 后，没有再起起来了

初创公司，且对自己的产品很有信心的人。会随时准备着产品大火，客户量激增，需要频繁大量的扩容数据库。

关于 binary_indexed_tree 解读和使用的博客

太难了 [image]

访问不到，只能自己造一造测试数据，脱敏工具挺多的，但是很少用到开发身上来，一般是用于数据的同步迁移啥的。 想其数据脱敏这个问题就让我想起之前写的那篇文章了 专栏 - 关于TiDB数据脱敏的一些想法 | TiDB 社区

关于这个问题，我在 Prometheus 的社区里得到了回答。 当集群节点和数据量的数据较大时，磁盘每隔一段时间会存在写入量过大，因为有数据的压缩和落盘，这个属于 Prometheus 的正常现象。 他们并不推荐修改任何参数来解决问题，修改参数可能会让 Prometheus 服务变的更加糟糕。 我们可以将 Prometheus 作为一个特别的节点来看待，修改该告警规则。 NODE_disk_write_latency - Prometheus server - Prometheus Monitoring System 顺便补充一下：磁盘写入延迟这个指标意义不大，重点可以看 IOPs …

物理机，NVMe 的 SSD，所以我们觉得对于这个配置来说，这个写入延迟是不能接受的

考虑谁的瞬时并发？ TiDB 的还是 Prometheus 的？

这里也不是 tiup 的版本号，是 tiup 里面 dm 组件的号码，tiup 有一堆组件，包括 cluster ,dm, cdc 等等组件，都有自己的版本号

考虐一下机器时区的问题，是否需要加个8.

院长 - 知乎 (zhihu.com) 没事会看看这位院长写的一些文章，感觉还可以！ 然后就是 AskTug 了

好的，感谢指导，原因我都知道了，主要是我觉得这个地方可以在文档中简单标注一下，不然对于刚使用的人，可能会在这个地方比较迷惑。

Lightning 文档对 tidb 模式下强行跳过 checksum 与 analyze 缺少描述。 - 建议&反馈 / 文档优化 - TiDB 的问答社区 (asktug.com) 已经发了！

我都准备自己去提PR了。既然这样的话，我还是去发个帖子吧

是的，在代码日志中，和文档都应该补全一下，排查了一中午，这个问题。

你配置文件写错了，Tiup里面配置的是 Alertmanager 服务信息，比如 ip 端口，部署的文件目录。 下面的 route 和 receivers 是 alertmanager 的配置文件 alertmanager.yml 里面配置的。 就是你在 deploy_dir 那个目录下 找到 alertmanager-9093/conf 里面的 alertmanager.yml 文件，然后在这个文件里面配置你具体的告警信息。