Briefly, this error occurs when Elasticsearch’s Snapshot Lifecycle Management (SLM) tries to clean up old snapshots but doesn’t find any repositories to fetch. This could be due to misconfiguration or deletion of repositories. To resolve this issue, you can either create a new repository or reconfigure the existing one. Also, ensure that the SLM policy is correctly set to point to the existing repository. Lastly, check the Elasticsearch logs for any related errors that might help in troubleshooting.
This guide will help you check for common problems that cause the log ” there are no repositories to fetch; SLM retention snapshot cleanup task complete ” to appear. To understand the issues related to this log, read the explanation below about the following Elasticsearch concepts: plugin, task, repositories, snapshot.
Overview
A task is an Elasticsearch operation, which can be any request performed on an Elasticsearch cluster, such as a delete by query request, a search request and so on. Elasticsearch provides a dedicated Task API for the task management which includes various actions, from retrieving the status of current running tasks to canceling any long running task.
Examples
Get all currently running tasks on all nodes of the cluster
Apart from other information, the response of the below request contains task IDs of all the tasks which can be used to get detailed information about the particular task in question.
GET _tasks
Get detailed information of a particular task
Where clQFAL_VRrmnlRyPsu_p8A:1132678759 is the ID of the task in below request
GET _tasks/clQFAL_VRrmnlRyPsu_p8A:1132678759
Get all the current tasks running on particular nodes
GET _tasks?nodes=nodeId1,nodeId2
Cancel a task
Where clQFAL_VRrmnlRyPsu_p8A:1132678759 is the ID of the task in the below request
POST /_tasks/clQFAL_VRrmnlRyPsu_p8A:1132678759/_cancel?pretty
Notes
- The Task API will be most useful when you want to investigate the spike of resource utilization in the cluster or want to cancel an operation.
Overview
An Elasticsearch snapshot provides a backup mechanism that takes the current state and data in the cluster and saves it to a repository (read snapshot for more information). The backup process requires a repository to be created first. The repository needs to be registered using the _snapshot endpoint, and multiple repositories can be created per cluster. The following repository types are supported:
Repository types
Repository type | Configuration type |
---|---|
Shared file system | Type: “fs” |
S3 | Type : “s3” |
HDFS | Type :“hdfs” |
Azure | Type: “azure” |
Google Cloud Storage | Type : “gcs” |
Examples
To register an “fs” repository:
PUT _snapshot/my_repo_01 { "type": "fs", "settings": { "location": "/mnt/my_repo_dir" } }
Notes and good things to know
- S3, HDFS, Azure and Google Cloud require a relevant plugin to be installed before it can be used for a snapshot.
- The setting, path.repo: /mnt/my_repo_dir needs to be added to elasticsearch.yml on all the nodes if you are planning to use the repo type of file system. Otherwise, it will fail.
- When using remote repositories, the network bandwidth and repository storage throughput should be high enough to complete the snapshot operations normally, otherwise you will end up with partial snapshots.
Log Context
Log “there are no repositories to fetch; SLM retention snapshot cleanup task complete” classname is SnapshotRetentionTask.java.
We extracted the following from Elasticsearch source code for those seeking an in-depth context :
.map(SnapshotLifecyclePolicy::getRepository) .collect(Collectors.toSet()); logger.trace("fetching snapshots from repositories: {}"; repositioriesToFetch); if (repositioriesToFetch.isEmpty()) { logger.info("there are no repositories to fetch; SLM retention snapshot cleanup task complete"); return; } // Finally; asynchronously retrieve all the snapshots; deleting them serially; // before updating the cluster state with the new metrics and setting 'running' // back to false