mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-28 17:34:17 -04:00
Since #104614 the top-level repo troubleshooting page is just a short paragraph which talks about "this page" but in fact refers to information spread across a number of subsequent pages. It's not obvious to the reader that they need to use the navigation menu to get to the information they seek. Moreover we link to this page from an exception message today so there's a reasonable chance that users will find it when trying to troubleshoot a genuine problem. This commit rewords things slightly and adds links to the subsequent pages to the body of the page to avoid this confusion.
50 lines
2.4 KiB
Text
50 lines
2.4 KiB
Text
[[add-repository]]
|
|
== Troubleshooting broken repositories
|
|
|
|
There are several situations where the <<health-api, Health API>> might report an issue
|
|
regarding the integrity of snapshot repositories in the cluster. The following pages explain
|
|
the recommended actions for diagnosing corrupted, unknown, and invalid repositories:
|
|
|
|
- <<diagnosing-corrupted-repositories>>
|
|
- <<diagnosing-unknown-repositories>>
|
|
- <<diagnosing-invalid-repositories>>
|
|
|
|
[[diagnosing-corrupted-repositories]]
|
|
=== Diagnosing corrupted repositories
|
|
|
|
Multiple {es} deployments are writing to the same snapshot repository. {es} doesn't
|
|
support this configuration and only one cluster is allowed to write to the same
|
|
repository. See <<snapshot-repository-contents>> for potential side-effects of
|
|
corruption of the repository contents, which may not be resolved by the following
|
|
guide.
|
|
To remedy the situation mark the repository as read-only or remove it from all the
|
|
other deployments, and re-add (recreate) the repository in the current deployment:
|
|
|
|
include::{es-ref-dir}/tab-widgets/troubleshooting/snapshot/corrupt-repository-widget.asciidoc[]
|
|
|
|
|
|
[[diagnosing-unknown-repositories]]
|
|
=== Diagnosing unknown repositories
|
|
|
|
When a snapshot repository is marked as "unknown", it means that an {es} node is
|
|
unable to instantiate the repository due to an unknown repository type. This is
|
|
usually caused by a missing plugin on the node. Make sure each node in the cluster
|
|
has the required plugins by following the following steps:
|
|
|
|
1. Retrieve the affected nodes from the affected resources section of the health report.
|
|
2. Use the <<cluster-nodes-info,nodes info API>> to retrieve the plugins installed on each node.
|
|
3. Cross reference this with a node that works correctly to find out which plugins are missing
|
|
and install the missing plugins.
|
|
|
|
|
|
[[diagnosing-invalid-repositories]]
|
|
=== Diagnosing invalid repositories
|
|
|
|
When an {es} node faces an unexpected exception when trying to instantiate a snapshot
|
|
repository, it will mark the repository as "invalid" and write a warning to the log file.
|
|
Use the following steps to diagnose the underlying cause of this issue:
|
|
|
|
1. Retrieve the affected nodes from the affected resources section of the health report.
|
|
2. Refer to the logs of the affected node(s) and search for the repository name.
|
|
You should be able to find logs that will contain relevant exception.
|
|
3. Try to resolve the errors reported.
|