Birdwatcher 进阶使用指南

写在最前

  敬畏生产！——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 多平台发布

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。