共计 3388 个字符，预计需要花费 9 分钟才能阅读完成。
写在最前
敬畏生产！——zilliz 技术总监栾小凡
Birdwatcher 对 Etcd 的写操作必须有 Dry run ——某匿名 Birdwatcher 作者
用 Birdwatcher 操作前先备份！——某匿名 Birdwatcher 作者
Birdwatcher 作为一款 Milvus 2.x 元数据工具，自 2022 年诞生，目前已正式公布至 v1.0.1 版本。依据之前的文章，大家曾经对 Birdwatcher 有了根本的理解。不过，大部分用户可能并不分明 Birdwatcher 的真正实力，轻轻走漏一下，在版本公布期间，Birdwatcher 曾经帮忙 Milvus 社区的开发者、用户定位和解决了若干问题。而 Birdwatcher 的 Etcd 备份曾经成为 Milvus issue 中“景象”“日志”“Birdwatcher 备份”三大常客之一。
本文将通过社区中几个常见的典型场景，为大家介绍 Birdwatcher 在 Milvus 的优化和问题定位中起到何种作用以及用户该如何去应用它。
性能问题剖析
Milvus 2.x 作为一款反对流批一体的向量数据库，能同时解决流式（未创立索引）和批式（已创立）的数据。因为向量记录自身的个性，对于流式的数据的查问（ANN、点查等）通常会比批式数据慢。这往往是在理论场景中查问性能降落 / 不稳固的起因。
在理论生产环境举荐应用 Info 级别的日志，在这个级别下，咱们通常无奈通过日志信息获知是否在 QueryNode 上产生的流式数据的查问。不止如此，在旧版本的 Promethues Dashboard 上，也无奈查问此信息。
此时，Birdwatcher 闪亮退场：
Birdwatcher 提供了查问 show segment-index 命令，用来查问 segment 的索引构建进度：
（注：旧版本截图）
上图为 issue 中用户提供的截图，从中能够看到有局部 segment 的索引始终处于“Unissued/InProgress”状态，即数据处于无索引状态，因而，所有的搜寻都处于暴搜状态导致性能降落。
https://github.com/milvus-io/milvus/issues/19042
https://github.com/milvus-io/milvus/issues/20012
对于没有部署 promethues 监控的用户（这里还是举荐大家部署的！），能够应用 Birdwatcher 来疾速查问 querynode 上的 segment 状态。
2.1.x 零碎卡死的修复
在 Milvus 2.1.x 版本中，因为一些曾经修复的 bug，collection 的 load/release 操作可能会因为内存或者其它问题被卡死导致系统无奈服务，在“远古”时代，Birdwatcher 是平安清理 Querycoord 上被卡死的 Load/Release 操作的工具。
具体 issue 参见：
https://github.com/milvus-io/milvus/issues/19061
https://github.com/milvus-io/milvus/issues/19586
https://github.com/milvus-io/milvus/issues/19818
另外，倡议仍在应用 Milvus 2.1.x 版本的用户降级至 2.2 版本，降级链接参见：https://milvus.io/docs/upgrade_milvus_cluster-helm.md
元数据修复
Etcd 元数据是 Milvus 2.x 得以失常运行的基本，然而在某些非凡状况下，如：
- 应用有特定 bug 的开发版本
- 谬误的降级形式
- 某些未修复的暗藏 bug
可能会导致 Milvus 的元数据产生问题，而这正是 Birdwatcher 的强项。
Empty Segment
在零碎中，设计上不容许一个没有任何 binlog、statslog 和 deltalog 的 sealed segment 存在，然而因为 2.1 版本中一个曾经修复的 bug，在重启集群时，会产生一个行数为 0 的空 segment，使得零碎进入一个无奈复原的谬误状态。
这种时候，通过内部 API 是无奈疾速地清理此问题，所以 Birdwatcher 为这个场景提供了一个clean-empty-segment (正式release 更名为 remove segment)
https://github.com/milvus-io/milvus/issues/16451
Segment Binlog 和索引文件不匹配
在以后的 Milvus 零碎中，索引文件和 binlog 是“一一对应”的（实际上是一批对一批，原谅一个技术人对细节形容的强迫症），咱们会在元数据中记录这批 binlog 的总行数和索引文件对应数据的总行数。
而因为一个设计上的忽略，在旧版本的 Milvus 零碎中，呈现局部数据被反复落盘并且多余索引文件的状况。这会导致 segment 在加载时元数据校验失败，最终引起 Load 操作报错。
最终通过 Birdwatcher 的备份定位到索引文件和 binlog 的文件的对应问题，并且提供了修复此问题的命令：
详情见：
https://github.com/milvus-io/milvus/issues/19500
残留的 Segment 信息
这个场景是某位社区用户提供的，造成 bug 的初始起因已不可考，然而从日志能够看到零碎处于一个 Etcd 元数据和对象存储不匹配的状态。即 Etcd 的元数据记录该 segment 的 binlog/statslog/deltalog 为如下若干文件，然而在对应的 minio 或者 s3 的门路下，文件曾经被删除了（体现为报错—— NoSuchKey）。
在认为该 segment 曾经被 compacted，并且数据残缺的状况下，引入了下列命令：remove segment
https://github.com/milvus-io/milvus/issues/19610
远古 Channel checkpoint
在 Milvus 2.2 之前，各个组件从 MQ 生产数据的 checkpoint 是由所有对应的 segment 的 checkpoint 计算而来的。这个逻辑易错且容易引入各种 bug，所以在 2.2 版本咱们从新设计了 channel checkpoint 机制。
不过，如果零碎是从 Milvus 低版本升级到 2.2.x，那么零碎还须要从 segment 从新计算一个 channel checkpoint，而这个 checkpoint 可能因为低版本的各种问题非常落后（先于以后工夫若干天）。这会导致系统须要很长的复原工夫，在某些状况下甚至无奈复原。
遇到此类问题的时候，就须要 birdwatcher 来疾速止血。咱们为此类问题退出了如下命令，将对应 channel 的 checkpoint 设置为对应 topic 的指定 position，让零碎能够疾速复原可服务状态：
1 repair checkpoint --collection 437744071571606912 --vchannel by-dev-rootcoord-dml_3_437744071571606912v1 --mq_type kafka --address localhost:9092 --set_to latest-msgid
2 repair checkpoint --collection 437744071571606912 --vchannel by-dev-rootcoord-dml_3_437744071571606912v1 --mq_type pulsar --address pulsar://localhost:6650 --set_to latest-msgid
https://github.com/milvus-io/milvus/issues/21527
残留 Channel Watch 信息
线下用户从 2.1 降级 2.2 时，替换了 pulsar 集群，然而复用了 etcd 和对象存储（并且配置 RootPath 完全相同），导致音讯队列和 Etcd 产生不统一。
这个时候会导致系统一直生产一个不存在的 topic，并且因为其工夫点十分长远，会导致 pulsar 集群的资源应用异样（打在了冷数据上）。这就使得零碎处于一个十分不稳固的状态，于是 Birdwatcher 为此提供了修复命令：
以上就是本次无关 Birdwatcher 场景的全部内容，欢送有趣味的小伙伴应用或退出奉献代码的行列！
本文由 mdnice 多平台公布
