关于 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 文件，然后在这个文件里面配置你具体的告警信息。

这个报错好像是 etcd 的报错，排查下PD的状态和监控有没有啥问题， etcdserver: http2Server.HandleStreams failed to read frame · Issue #7926 · etcd-io/etcd (github.com) 节点都正常的话，可以尝试重启一下 PD 节点。

In Search of an Understandable Consensus Algorithm (mit.edu) 学吧兄弟们，学无止境！ 补一篇上月看的： Volcano - An Extensible and Parallel Query Evaluation System (paperhub.s3.amazonaws.com)

这个以 Dashboard 为准吧，因为 Dashboard 里面是直接取的日志中 SQL 的信息记录。 Grafana 中的数据，是来自于 Prometheus ，数据一般是经过一些计算后再展现的，有一定的偏差。 具体计算方法你可以通过点击 Slow query ，Edit 这个面板，看一下 PQL 表达式。这种比较偏统计类的相关知识，n你可以分析下。 [image]

我还是比较佛系的，哈哈哈哈