排查损坏的仓库
edit排查损坏的仓库
edit在某些情况下，Health API可能会报告集群中快照仓库的完整性问题。以下页面解释了诊断损坏、未知和无效仓库的推荐操作：
诊断损坏的仓库
edit多个 Elasticsearch 部署正在写入同一个快照仓库。Elasticsearch 不支持这种配置，只允许一个集群写入同一个仓库。请参阅 仓库内容 以了解仓库内容可能出现的损坏副作用，这些副作用可能无法通过以下指南解决。 要解决这种情况，请将仓库标记为只读或从所有其他部署中移除它，并在当前部署中重新添加（重新创建）仓库：
修复损坏的存储库将需要在多个部署中进行更改，这些部署写入同一个快照存储库。 只有一个部署必须写入存储库。将继续写入存储库的部署将被称为“主要”部署（当前集群）， 而我们将标记为只读的其他部署将被称为“次要”部署。
首先将仓库在辅助部署上标记为只读：
使用 Kibana
- 登录到 Elastic Cloud 控制台。
-
在Elasticsearch Service面板上，点击您的部署名称。
如果您的部署名称被禁用，您的 Kibana 实例可能不健康，在这种情况下，请与 Elastic 支持 联系。如果您的部署不包含 Kibana，您需要做的就是 首先启用它。
-
打开您的部署的侧边导航菜单（位于左上角的Elastic标志下方），然后转到堆栈管理 > 快照和还原 > 仓库。
- 仓库表应该现在可见。点击仓库右侧的铅笔图标以标记为只读。在打开的编辑页面上，向下滚动并勾选“只读仓库”。点击“保存”。 或者，如果删除仓库是更可取的，请在仓库表中选择仓库名称左侧的复选框，然后点击表左上角的“删除仓库”红色按钮。
此时，只有主（当前）部署将存储库标记为可写。 Elasticsearch 认为它已损坏，因此需要删除并重新添加存储库，以便 Elasticsearch 可以继续使用它：
请注意，我们现在正在配置主（当前）部署。
-
打开主部署的侧边导航菜单（位于左上角的Elastic标志下方），然后转到堆栈管理 > 快照和还原 > 仓库。
- 点击仓库右侧的铅笔图标。在打开的编辑页面中，向下滚动并点击“保存”，无需对现有设置进行任何更改。
修复损坏的存储库将需要在多个写入同一快照存储库的集群中进行更改。 只有一个集群必须写入存储库。我们称希望继续写入存储库的集群为“主”集群（当前集群）， 而将我们标记为只读的其他集群称为“次”集群。
让我们先处理次要集群：
-
获取仓库的配置：
GET _snapshot/my-repo
响应将会是这样的：
-
使用上面检索到的设置，添加
readonly: true选项以将其标记为只读： -
或者，可以使用以下方法删除仓库：
DELETE _snapshot/my-repo
响应将会是这样的：
{ "acknowledged": true }
此时，只有主（当前）集群将存储库标记为可写。 Elasticsearch认为它是损坏的，因此让我们重新创建它，以便Elasticsearch可以继续使用它。 请注意，现在我们正在配置主（当前）集群：
-
获取仓库的配置并将其配置保存下来，因为我们将在重新创建仓库时使用它：
GET _snapshot/my-repo
-
使用我们上面获得的配置，让我们重新创建仓库：
PUT _snapshot/my-repo { "type": "s3", "settings": { "bucket": "repo-bucket", "client": "elastic-internal-71bcd3", "base_path": "myrepo" } }响应将会是这样的：
{ "acknowledged": true }
诊断未知仓库
edit当快照仓库被标记为“未知”时，意味着Elasticsearch节点由于未知仓库类型而无法实例化该仓库。这通常是由于节点上缺少插件引起的。请按照以下步骤确保集群中的每个节点都安装了所需的插件：
- 从健康报告的影响资源部分获取受影响的节点。
- 使用节点信息API来检索每个节点上安装的插件。
- 将此与正常工作的节点进行交叉参考，找出缺失的插件并安装缺失的插件。
诊断无效的仓库
edit当Elasticsearch节点在尝试实例化快照仓库时遇到意外异常，它会将该仓库标记为“无效”并写入一条警告到日志文件中。使用以下步骤来诊断此问题的根本原因：
- 从健康报告的影响资源部分检索受影响的节点。
- 参考受影响节点(s)的日志并搜索仓库名称。 你应该能够找到包含相关异常的日志。
- 尝试解决报告的错误。