mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
e063d1ddc8
Removes the `[discrete]` line from the docs introduced in #102050 so that these subsections are nested at the right level.
95 lines
4.3 KiB
Text
95 lines
4.3 KiB
Text
[[snapshots-filesystem-repository]]
|
|
=== Shared file system repository
|
|
|
|
include::{es-repo-dir}/snapshot-restore/on-prem-repo-type.asciidoc[]
|
|
|
|
Use a shared file system repository to store snapshots on a shared file system.
|
|
|
|
To register a shared file system repository, first mount the file system to the
|
|
same location on all master and data nodes. Then add the file system's path or
|
|
parent directory to the `path.repo` setting in `elasticsearch.yml` for each
|
|
master and data node. For running clusters, this requires a
|
|
<<restart-cluster-rolling,rolling restart>> of each node.
|
|
|
|
Supported `path.repo` values vary by platform:
|
|
|
|
include::{es-repo-dir}/tab-widgets/register-fs-repo-widget.asciidoc[]
|
|
|
|
[[filesystem-repository-settings]]
|
|
==== Repository settings
|
|
|
|
`chunk_size`::
|
|
(Optional, <<byte-units,byte value>>)
|
|
Maximum size of files in snapshots. In snapshots, files larger than this are
|
|
broken down into chunks of this size or smaller. Defaults to `null` (unlimited
|
|
file size).
|
|
|
|
`compress`::
|
|
(Optional, Boolean)
|
|
If `true`, metadata files, such as index mappings and settings, are compressed
|
|
in snapshots. Data files are not compressed. Defaults to `true`.
|
|
|
|
`location`::
|
|
(Required, string)
|
|
Location of the shared filesystem used to store and retrieve snapshots. This
|
|
location must be registered in the `path.repo` setting on all master and data
|
|
nodes in the cluster.
|
|
|
|
`max_number_of_snapshots`::
|
|
(Optional, integer)
|
|
Maximum number of snapshots the repository can contain.
|
|
Defaults to `Integer.MAX_VALUE`, which is `2^31-1` or `2147483647`.
|
|
|
|
include::repository-shared-settings.asciidoc[]
|
|
|
|
==== Troubleshooting a shared file system repository
|
|
|
|
{es} interacts with a shared file system repository using the file system
|
|
abstraction in your operating system. This means that every {es} node must be
|
|
able to perform operations within the repository path such as creating,
|
|
opening, and renaming files, and creating and listing directories, and
|
|
operations performed by one node must be visible to other nodes as soon as they
|
|
complete.
|
|
|
|
Check for common misconfigurations using the <<verify-snapshot-repo-api>> API
|
|
and the <<repo-analysis-api>> API. When the repository is properly configured,
|
|
these APIs will complete successfully. If the verify repository or repository
|
|
analysis APIs report a problem then you will be able to reproduce this problem
|
|
outside {es} by performing similar operations on the file system directly.
|
|
|
|
If the verify repository or repository analysis APIs fail with an error
|
|
indicating insufficient permissions then adjust the configuration of the
|
|
repository within your operating system to give {es} an appropriate level of
|
|
access. To reproduce such problems directly, perform the same operations as
|
|
{es} in the same security context as the one in which {es} is running. For
|
|
example, on Linux, use a command such as `su` to switch to the user as which
|
|
{es} runs.
|
|
|
|
If the verify repository or repository analysis APIs fail with an error
|
|
indicating that operations on one node are not immediately visible on another
|
|
node then adjust the configuration of the repository within your operating
|
|
system to address this problem. If your repository cannot be configured with
|
|
strong enough visibility guarantees then it is not suitable for use as an {es}
|
|
snapshot repository.
|
|
|
|
The verify repository and repository analysis APIs will also fail if the
|
|
operating system returns any other kind of I/O error when accessing the
|
|
repository. If this happens, address the cause of the I/O error reported by the
|
|
operating system.
|
|
|
|
TIP: Many NFS implementations match accounts across nodes using their _numeric_
|
|
user IDs (UIDs) and group IDs (GIDs) rather than their names. It is possible
|
|
for {es} to run under an account with the same name (often `elasticsearch`) on
|
|
each node, but for these accounts to have different numeric user or group IDs.
|
|
If your shared file system uses NFS then ensure that every node is running with
|
|
the same numeric UID and GID, or else update your NFS configuration to account
|
|
for the variance in numeric IDs across nodes.
|
|
|
|
[[repository-fs-linearizable-registers]]
|
|
==== Linearizable register implementation
|
|
|
|
The linearizable register implementation for shared filesystem repositories is
|
|
based around file locking. To perform a compare-and-exchange operation on a
|
|
register, {es} first locks he underlying file and then writes the updated
|
|
contents under the same lock. This ensures that the file has not changed in the
|
|
meantime.
|