-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DOC] Remote Store feature documentation changes for 2.10.0 release #4875
Comments
@Naarcha-AWS The main page changes are pending. Providing details below |
Remote Backed Storage: Main Page OverviewRemote-backed storage offers OpenSearch users a new way to protect against data loss by automatically creating backups of all index operations and sending them to the configured remote store. When remote backed storage is enabled for a cluster, it uses replication type as segment. See Segment replication for additional information. With remote-backed storage, when a write request lands on the primary shard, the request is indexed to Lucene on the primary shard only. The corresponding translog is then uploaded to remote translog store. OpenSearch does not send the write request to the replicas, but rather performs a primary term validation to confirm that the request originator shard is still the primary shard. Primary term validation ensures that the acting primary shard fails if it becomes isolated and is unaware of the cluster manager electing a new primary. Once segments are created on primary as part of refresh/flush/merge flow, segments are uploaded to remote segment store and the replica shards source the copy from the same store. This frees up primary from data copying operation. With translog and segment data uploaded to remote store, remote backed storage achieves request level durability. ConfigurationRemote backed storage feature is a cluster level setting and can only be enabled during bootstrap of the cluster. Once cluster is bootstrapped, the feature can not be enabled or disabled. This helps in providing durability guarantees at the cluster level. The communication to the configured remote cluster happens via repository plugin interface. With this, all the existing implementations of the repository plugin (Azure Blob Store, Google Cloud Storage, AWS S3 etc) are compatible with remote backed storage. To enable remote backed storage for a given cluster, we need to provide repository details as node attributes in each node’s opensearch.yml. A sample set of node attributes look like:
We don’t have to provide 3 different repositories for segment, translog and state. All 3 stores can share the same repository. Once cluster is created with remote_store settings, all the indices created in that cluster will start uploading data to the configured remote store. RestoreTo restore an index from a remote backup, such as in the event of a node failure, following are 2 options: Restore only unassigned shards
Restore all the shards of a given index
Related SettingsYou can use following cluster level settings to tune your cluster as per the workload. For more information related to these settings, refer: https://opensearch.org/docs/latest/api-reference/cluster-api/cluster-settings/
Next Steps
|
Reopening this issue for now. |
What do you want to do?
Tell us about your request. Provide a summary of the request and all versions that are affected.
The text was updated successfully, but these errors were encountered: