[DOCS] Add CCR limitation #87348
[DOCS] Add CCR limitation #87348
Conversation
closes #86121
Leaf-Lin
added
>docs
Leaf-Lin
added
the
Team:Distributed (Obsolete)
|
@Leaf-Lin, I moved this content to a section within the overall CCR context, moved the links to other pages into the separate sections, and made some additional edits. Let me know if these changes work for you. |
|
Pinging @elastic/es-distributed (Team:Distributed) |
|
Pinging @elastic/es-docs (Team:Docs) |
|
@elasticmachine run elasticsearch-ci/docs |
|
@Leaf-Lin should we also add that CCR doesn't work across clusters that are individually configured with private link? |
|
Perhaps someone from @elastic/es-distributed can review these changes for accuracy. |
|
@elasticmachine update branch |
|
@Leaf-Lin, I consolidated this information considerably. I don't think that we need to get into the implementation details of where things are stored, and can instead list the data that isn't replicated with CCR and inform users that they'll need to manually replicate this information. Let me know if this change works for you, and if so, I'll merge. |
docs/reference/ccr/index.asciidoc
Outdated
| * <<snapshots-register-repository,Snapshot repository settings>> | ||
| * <<modules-cluster,Cluster settings>> | ||
| * <<searchable-snapshots,Searchable snapshot>> | ||
| * <<restore-index-data-stream,Restored indices>> |
There was a problem hiding this comment.
Is this true, would auto-follow patterns not hit that?
There was a problem hiding this comment.
This was referring to the problem described in this issue: #87055
There was a problem hiding this comment.
Based on the conversation in #87055, it sounds like restored indices aren't replicated if the leader index is deleted and then restored, but the original replicated index still exists in the remote cluster. The restored index in the leader cluster gets a new UUID, so the auto-follow pattern on the remote cluster sees it as new index, but it's actually just a replicated index.
This sounds like an edge case that we could call attention to, but it seems like restored indices would be replicated if the underlying leader index is still intact. Is that true @henningandersen?
There was a problem hiding this comment.
I agree @lockewritesdocs, it will follow just fine if the restore results in an unoccupied name on the follower. This is similar to any sort of naming conflict on the follower though a delete and restore on the leader side is possibly a common cause of this.
I'd opt to remove this, since it is not true that restored indices are not followed.
There was a problem hiding this comment.
👍 Sounds good @henningandersen -- I've removed "Restored indices" from the list of things that aren't followed.
* Add CCR limitation closes elastic#86121 * Add restored index auto follow pattern restriction elastic#87055 * Moving content to existing CCR page + several changes * Remove sections to consolidate limitation information * Delete separate file * Remove restored indices from list of things that aren't replicated Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
* Add CCR limitation closes elastic#86121 * Add restored index auto follow pattern restriction elastic#87055 * Moving content to existing CCR page + several changes * Remove sections to consolidate limitation information * Delete separate file * Remove restored indices from list of things that aren't replicated Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
* Add CCR limitation closes elastic#86121 * Add restored index auto follow pattern restriction elastic#87055 * Moving content to existing CCR page + several changes * Remove sections to consolidate limitation information * Delete separate file * Remove restored indices from list of things that aren't replicated Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
* Add CCR limitation closes #86121 * Add restored index auto follow pattern restriction #87055 * Moving content to existing CCR page + several changes * Remove sections to consolidate limitation information * Delete separate file * Remove restored indices from list of things that aren't replicated Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
* Add CCR limitation closes #86121 * Add restored index auto follow pattern restriction #87055 * Moving content to existing CCR page + several changes * Remove sections to consolidate limitation information * Delete separate file * Remove restored indices from list of things that aren't replicated Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
* Add CCR limitation closes #86121 * Add restored index auto follow pattern restriction #87055 * Moving content to existing CCR page + several changes * Remove sections to consolidate limitation information * Delete separate file * Remove restored indices from list of things that aren't replicated Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Adam Locke <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Outlining CCR limitations in today's implementation.
closes #86121
The searchable snapshot part should also link to #67668 and #81238
Preview link: https://elasticsearch_87348.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/xpack-ccr.html#ccr-limitations