零停机时间索引部署

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 'https://127.0.0.1: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 'https://127.0.0.1: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 构建的内容、您的使用案例以及您的具体需求。

无论您选择哪个选项，我们都期待收到您的来信！