(DOC +) Add resolutions to Allocation Explain examples #108263
Conversation
anniegale9538
added
>enhancement
>docs
|
Documentation preview: |
|
@anniegale9538 please enable the option "Allow edits and access to secrets by maintainers" on your PR. For more information, see the documentation. |
elasticsearchmachine
added
v8.15.0
external-contributor
|
Pinging @elastic/es-docs (Team:Docs) |
|
Pinging @elastic/es-distributed (Team:Distributed) |
| @@ -180,6 +180,8 @@ primary shard that was previously allocated. | |||
| ---- | |||
| // NOTCONSOLE | |||
|
|
|||
| The shard in the example above errors `no_valid_shard_copy` due to `NODE_LEFT`. The first step to recover is to make sure all nodes are in the cluster. Then, if the error continues after a <<cluster-reroute,cluster reroute>>, the data will need to be <<snapshots-restore-snapshot,restored from snapshot>>. | |||
There was a problem hiding this comment.
I think this info is valuable, but I don't think that it's the appropriate location for the recovery steps. We have a page that talks about recovering lost nodes - we might consider linking to that doc, and enhancing it as needed. This way, all of the info is centralized. Let me know what you think.
There was a problem hiding this comment.
👋🏽 I'm on board to either page as long as we can write an actionable commentary for this response example. (I helped Annie write her first doc PR!) The Support back story is that users search for the explicit error and no_valid_shard_copy only shows on this page.
We could just link or also add the error's literal string on the recovery data for a lost primary shard. If we cross-link/pollinate, could y'all also kindly consider reformatting the destination so these don't look like sequential steps (which'd destroy your data right after recovering it?):
There was a problem hiding this comment.
@stefnestor this is probably my unfamiliarity with this area of the product, but can you explain which steps shouldn't be performed sequentially? using the cluster reroute API replacing the primary with a replica?
Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
|
@DaveCTurner @shainaraskas @stefnestor I trust whatever y'all think is best practice! I'm still new to Elastic and just excited to be here and to learn to contribute in a way that will benefits our customers the most. If referencing existing documentation is preferred, I am more than okay with that! |
Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
|
@shainaraskas sorry for the delay, loved the tip options, I think it's ready for you to re-review! Thanks for your patience as I'm learning! |
|
@anniegale9538 please wait for another review from Dave before you merge :) |
Co-authored-by: David Turner <david.turner@elastic.co>
👋 @shainaraskas @DaveCTurner @anniegale9538 as follow-up to #108263, this fixes the now targeted doc to make the recovery options look like alternatives rather than sequential steps.
* (+Doc) Recover from "no_valid_shard_copy" 👋 @shainaraskas @DaveCTurner @anniegale9538 as follow-up to #108263, this fixes the now targeted doc to make the recovery options look like alternatives rather than sequential steps. * Apply suggestions from code review Co-authored-by: Ievgen Degtiarenko <ievgen.degtiarenko@elastic.co> --------- Co-authored-by: Ievgen Degtiarenko <ievgen.degtiarenko@elastic.co>
👋 hi, team! This adds a couple resolution steps to the Allocation Explain examples, that I think could be useful for our customers!
Let me know what you think!