[DOCS] CCR disaster recovery #91491
[DOCS] CCR disaster recovery #91491
Conversation
|
Documentation preview: |
Leaf-Lin
added
>docs
elasticsearchmachine
added
Team:Distributed (Obsolete)
|
Pinging @elastic/es-docs (Team:Docs) |
|
Pinging @elastic/es-distributed (Team:Distributed) |
Remove immutable restrictions and add update/delete by query instructions.
|
@henningandersen , could you please confirm that this doc is ok to be published? Preview available:
Also, what do you think about @naj-h 's concern in #91491 (comment) |
There was a problem hiding this comment.
Left a few comments, otherwise this looks good.
Also, what do you think about @naj-h 's concern in #91491 (comment)
I think it is worth mentioning too. For uni-directional it is somewhat outside the story's main path in that this does not concern a DR but rather the DR-site being unavailable. So some mention towards the bottom makes most sense to me.
In the bi-directional case it is more troubling. I think you'll need to mention the error you can get and then how to remedy (delete and re-bootstrap).
I think we should not advice to set the setting higher (has other consequences). Perhaps not mention it directly but link to the documentation for it.
| [source,console] | ||
| ---- | ||
| ### On the cluster identified from the previous step ### | ||
| POST logs-generic-default/_update_by_query |
There was a problem hiding this comment.
Would they not simply use individual updates or deletes instead (maybe through bulk)? I can imagine the query above giving out documents that are on both sides and they'd have to partition the document _id to use on each cluster.
There was a problem hiding this comment.
Another common request from users is to perform update or deletes in bi-directional CCR.
The purpose of this section is to demonstrate the possibility of doing so. Users are still welcome to bulk delete/update on the leader index as they wish.
| + | ||
| [source,logstash] | ||
| ---- | ||
| ### On Logstash server ### |
There was a problem hiding this comment.
Would logstash not be a single point of failure?
I think the original blog post would index data locally in the current DC to the local cluster, avoiding this issue to some degree.
There was a problem hiding this comment.
Exactly. Unfortunately, the original blog post having DC locality isolation does not satisfy most of the bi-directional CCR use cases where users would have a single source of ingestion going into two separated cluster. That's part of the reason I was working on this tutorial to highlight this use case.
There are other possibility avoiding Logstash being the single point of failure, but it is outside the scope of this tutorial.
|
@elasticmachine merge upstream |
|
@elasticmachine update branch |
|
@elasticmachine run elasticsearch-ci/docs-check |
|
@elasticmachine test this please |
|
@elasticmachine retest this please |
Similar to #87099, we should also have a tutorial page for bi-directional disaster recovery.
This is similar to the blog: https://www.elastic.co/blog/bi-directional-replication-with-elasticsearch-cross-cluster-replication-ccr, but it broadens the use case with modernized elasticserach feature (data stream). It also contains:
And provide updates and delete instructions.