零停机索引部署
假设您的数据库发生了需要与生产环境中的 Meilisearch 索引同步的更改。您会怎么做?

Meilisearch v0.30 已于本月早些时候发布。通过此次发布,我们的主要目标是使 Meilisearch 的工作流程尽可能顺畅。毕竟,我们正朝着 v1 版迈进,目的地近在咫尺。为此,实现零停机索引部署是至关重要的一步。我们很高兴地宣布,v0.30 解决了这个问题,使得在生产环境中更新索引比以往任何时候都更加容易。继续阅读以了解更多关于该功能的工作原理!
挑战
假设您的数据库发生了需要与生产环境中的 Meilisearch 索引同步的更改。您会怎么做?如果在 Meilisearch v0.29 中,您可能会
更新索引
🙅♀️ 很简单,对吧?但如果您曾尝试过,那么您应该已经知道……
在生产索引接收搜索查询时更新它,可能会导致结果不一致甚至信息丢失。您肯定不想提供这样的搜索体验,对吗?否则,您就不会使用 Meilisearch 了😁
删除索引,创建同名新索引,并重新索引数据
⌛ 每一步都会花费一些时间。即使只是几秒钟,那也是几秒钟的停机时间……而且这至少需要三个请求!这里几秒,那里几秒,加起来就可能导致数分钟的停机时间!不,谢谢。
创建一个新索引并使用不同的名称,将更改在那里进行暂存,然后修改所有客户端以指向新索引
🤔 嗯,这不是最糟糕的选择。但同样,更新客户端会导致停机时间😞 在某些情况下,客户端更新何时推送到生产环境甚至不由开发人员决定。以 iOS 应用为例:Apple 必须在您发布新版本之前进行审核,这可能会严重拖延您的发布计划。
创建一个中间重定向层以避免停机时间
🧞 非常聪明!虽然这是一个好方法,但它并不是最直接的。它需要架构知识、时间和额外的工具。
您是不是很高兴再也不必做这些事情了?
灵丹妙药
Meilisearch 始终致力于提供最佳的开发者体验。
我们的团队在过去几个月里一直努力工作,经过多次迭代,他们提出了一个可以无缝集成到开发者技术栈中的解决方案:索引交换。
让我向您展示它是如何工作的。
假设您有一个生产环境中的索引——indexA
——您的客户端在此索引中进行搜索。您希望将主数据库中的更改与 Meilisearch 同步。为此,您可以按照以下步骤操作。
步骤 1:创建一个包含最新数据的新索引
首先,您需要创建一个索引——我们称之为 indexA_new
——它代表您希望部署到搜索客户端的 indexA
的新版本。添加数据库中的最新文档,并在必要时更新索引设置。
请不要忘记检查所有与索引创建相关的任务是否已成功完成,包括 indexCreation
、settingsUpdate
和 documentAdditionOrUpdate
任务类型。您可以使用 /tasks
路由来获取它们的进度信息。
步骤 2:测试新索引
在将索引推送到生产环境之前,您需要确保一切都按预期工作。
务必更新您可能随更新数据引入的任何新字段的设置。例如,您可能希望将新字段添加到 searchableAttributes
、filterableAttributes
和/或 sortableAttributes
。无论何时添加新数据,都不要忘记仔细检查搜索结果的相关性!
👉 请记住,searchableAttributes
列表不仅指定了可搜索的字段,还决定了属性排名顺序。请确保您可能引入的任何新字段都以正确的顺序添加到列表中。
步骤 3:交换索引
一旦您的 indexA_new
成功创建、填充数据并经过测试,就可以通过索引交换进行部署了。为此,请向 /swap-indexes
端点发送一个 POST
请求。在请求体中指定您要交换的索引。由于是交换,顺序无关紧要。
curl -X POST 'http://localhost:7700/swap-indexes' -H 'Content-Type: application/json' --data-binary '[ { "indexes": ["indexA", "indexA_new"] } ]'
👉 在受保护的 Meilisearch 实例中,用于交换索引的 API 密钥必须具有 indexes.swap
操作以及您希望交换的索引的访问权限。否则,Meilisearch 将抛出 invalid_api_key
错误。有关创建具有特定权限的 API 密钥的更多信息,请参阅文档。
您可以使用响应中的 taskUid
,通过 GET /tasks/{task_uid}
端点来跟踪请求的状态。成功的索引交换应如下所示
{ "uid": 23, "indexUid": null, "status":"succeeded", "type":"indexSwap", "details":{ "swaps": [ {"indexes": ["indexA", "indexA_new"]}, ] }, "duration": "PT1S", "enqueuedAt": "2021-08-10T14:29:17.000000Z", "startedAt": "2021-08-10T14:29:18.000000Z", "finishedAt": "2021-08-10T14:29:19.000000Z" }
您的索引已在零停机时间内完成交换!indexA
的文档、设置和任务历史(除任何已入队任务外)已与 indexA_new
的相应内容进行了交换。任务历史中所有提及 indexA
的地方都已被 indexA_new
替换,反之亦然(enqueued
任务保持不变)。
交换后,indexA_new
包含过时内容。您可以删除它,或者将其保留作为备份,以防万一出现问题需要回滚。有备无患!
就是这样!只有三个步骤,如果您喜欢冒险,也可以是两个。这还能更棒吗?
锦上添花之处🍰
如果我告诉您,您只需一个请求就可以交换多个索引,您会怎么想?
我没有开玩笑。单个请求可以交换任意数量的索引对。Meilisearch 可以同时部署所有更改。客户端将立即访问所有索引的新版本,而不会有任何停机时间。
curl -X POST 'http://localhost:7700/swap-indexes' -H 'Content-Type: application/json' --data-binary '[ { "indexes": ["indexA", "indexA_new"] }, { "indexes": ["indexB", "indexB_new"] }, { "indexes": ["indexC", "indexC_new"] } ]'
在上面的示例中,三个交换操作将同时且原子地发生。
等等,什么?
是的,您可以再读一遍。它是原子性的!要么所有索引都成功交换,要么一个也没有。要么所有内容都交换了,要么一个也没有。
这为什么重要?它能防止数据库中的部分更改,确保一致性,从而提供一流的搜索体验。
结论
如前所述,这项功能已经开发了几个月,其灵感都源于用户反馈。我们路线图上的 “交换索引”卡片获得了 38 票以及几乎同样多的评论,解释了这项功能是必不可少的使用场景。以下是我们最喜欢的一些例子
- “在尝试更改生产数据库规则以获得最佳结果时,这会非常有用。”
- “如果索引意外地以错误名称创建,或者由于各种原因需要重命名/更改它,这将很有帮助。”
- “我们需要它来清除所有已删除的项目。”
这些只是几个例子。这类见解对我们的团队非常有帮助,因为它使我们能够根据用户的需求来塑造产品。
尽管非常方便——您可以全面了解所有已提交、正在开发和已发布的功能创意——但路线图只是提供反馈的其中一种方式。
在我看来,GitHub 上的产品讨论区是阐述您需求的最佳场所之一。您可以与 Meilisearch 产品团队直接联系,而且由于它是公开的,任何人都可以参与并丰富这个过程。
最后一个选择是我们全新的 Discord 服务器。请不要犹豫加入我们,谈论您用 Meilisearch 构建了什么、您的用例以及您的具体需求。
无论您选择哪种方式,我们都期待您的反馈!