教程[15] MeiliSearch 升级

开篇废话

MeiliSearch 可能是我目前 20 年人生中碰到的最多 update break 的软件。

作为一个 Arch Linux 用户,每个月 -Syyu 是必然的,不过 Meilisearch 因为更新了数据需要重新导入之类的原因咕了好久都没更 春节闲的蛋疼的时候终于来更了。
由于升级体验实在过于糟糕,所以我没打算直接在原来的初体验文直接更新,而另开了个新帖子。

另外本文是个思路,大概就讲了更新软件该做些什么工作。

正文

首先我们大概有以下两个思路去适配新版本的 MeiliSearch:

  1. 运行出 bug 了再对着文档搞
  2. 浏览最近更改,本地适配完毕再来更新线上环境

我选择两个一起做

另外还要看看时间成本,如果更改过于多,不如当之前没用过,对着接口(文档)全部重构,就懒得看更新日志了。

浏览更改

想到上次用 MeiliSearch 还是在半年前,大概 v0.21 版本,我们顺着 MeiliSearch 的 GitHub Release 开始找

由于连 CHANGELOG.md 都跑路了所以才看 Release note 的

Github release 顺着找,作者们也知道自己的软件很多 Breaking changes 大概浏览下

  • v0.21.0
    • filters -> filter 然后语法有点变化 (从这个版本有能用的 web 页面了)
  • v0.22.0
    • 大概是一些排序之类的语法变化,好像有用到
  • v0.24.0
    • 看上去是 errorcode 之类的更改,不是客户端用官方 sdk 应该不影响
  • v0.25.0
    • API Key management (之前生成key鉴权的时候有用到)然后好像多了个任务列表的接口

(rc 为候选版本,一般不需要看,在正式版本里面应该是有重复提到的)

心理有数后就可以开始更新了。

主程序更新

此部分参考官方文档更佳

首先导出数据

MeiliSearch 各大版本的数据(data.ms)是不通用的,我们需要先 dump 出所有数据,然后在新版本的 MeiliSearch 再导入数据
简单来说就是 /var/lib/meilisearch/ 里面(文件路径自己定位啦 我这是这个)的 data.ms 是包括索引等其它东西的,并不是纯数据,我们需要 dump 出某一时刻的版本出来。

在这阶段我是建议不要运行依赖 MeiliSearch 的程序了,等下出现数据不同步情况就gg了。

curl -X POST 'http://127.0.0.1:7700/dumps'
{
  "uid": "20210212-114515191"
}

稍等片刻,大概就 dump 完成了
查看进度:

curl -X GET 'http://127.0.0.1:7700/dumps/:uid/status'
{
  "status": "done"
}

然后数据会在数据文件夹/dumps 里面
dump pwd
然后更新 MeiliSearch 本体(自己从 GitHub Releases 里面下)

# 更新命令 (自己想)
cd /var/lib/meilisearch/
mv data.ms data.ms.bak # 备份原来的,导入成功后可以删掉
meilisearch --import-dump dumps/uid.dump

然后等导入完成
update abort
太久没更新的话(由于跨的版本很大),甚至需要一个中间版本来更新,所以我们先把主程序更新到 v0.24,然后再更新到 v0.25.2 (截止目前的最新版本)

更新完成后,我们对着之前收集的更新日志处理下,比如鉴权模块被重写了,那就重新生成 key,排序方式似乎也被重置了,那就重新 post。

使用的项目更新

我使用 MeiliSearch 的项目是 @zaobao_bot ,在主程序更新后对应客户端 sdk 也要更新

yarn add meilisearch

更新到最新版本,然后再对着文档搞,一般来说就是哪里报错修哪里,不过我们浏览过更改的可以提前先改好一点。
update
update

此部分另外参考: https://blog.huggy.moe/posts/2022/7-meilisearch-3/

总结

在这之前都没有软件更新能让我折腾上一天的,这样舍弃兼容性的大更改可以甩掉很多包裹,不过会对依赖这个软件的项目或多或少有影响,也算是理解 RHEL 这样给上世纪包的企业级做法了

作为开发来说,做功能之前还是弄个路线图之类的规划好来,而不是随心所欲随便加/删/改,在不得不更改的时候标出 Breaking change 然后提醒使用者去配合改大概就好了(仁至义尽,已经通知到就好)。
作为程序依赖的开发者,对于依赖要跟踪其频道,在更新前留意下更新日志比较稳妥点,直接跑然后报错了再改也 ok。

然后 docker NixOS 的优势就出现了,线上环境不会因为版本问题而炸,可能方便多了。