Skip to content
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

[Writable Warm] Recovery/Replication flow for Composite Directory #13647

Open
Tracked by #13149
rayshrey opened this issue May 13, 2024 · 2 comments · May be fixed by #14670
Open
Tracked by #13149

[Writable Warm] Recovery/Replication flow for Composite Directory #13647

rayshrey opened this issue May 13, 2024 · 2 comments · May be fixed by #14670
Assignees
Labels
enhancement Enhancement or improvement to existing feature or request Roadmap:Search Project-wide roadmap label Storage:Remote v2.16.0 Issues and PRs related to version 2.16.0

Comments

@rayshrey
Copy link
Contributor

rayshrey commented May 13, 2024

Is your feature request related to a problem? Please describe

With the introduction of Composite Directory for Writable Warm, we will also need to modify it's replication/recovery flow since we only have partial data available locally in composite directory.

Describe the solution you'd like

Replication/Recovery flow should work for Composite Directory.
Will update this section with more details once have a concrete LLD for this.

Related component

Storage:Remote

Describe alternatives you've considered

N/A

Additional context

Writable Warm RFC - #12809
Composite Directory RFC - #12781

@mch2
Copy link
Member

mch2 commented May 13, 2024

A couple of things come to my head here on how this would be inefficient but I'm not sure if it would actually break.

We wouldn't want to download all files from the remote store given its a warm case. There are a couple of locations where this happens today - prior to recovery start, prior to engine open, and on an engine reset / failover case.

Second I think prior to engine open we fetch the latest SegmentInfos in memory and perform a local commit with SegmentInfos.commit so that the engine can start from reading the latest segments_n in the directory. I think this would still work but may be downloading more than we want to perform the commit. If thats the case we may need to update this flow to ensure the remote store has a commit file and load that.

@sohami sohami added Roadmap:Cost/Performance/Scale Project-wide roadmap label and removed Roadmap:Cost/Performance/Scale Project-wide roadmap label labels May 14, 2024
@mch2 mch2 removed the untriaged label May 14, 2024
@yigithub yigithub moved this to Release v2.16 (7/23/24) in Tiered Writable Index May 20, 2024
@nisgoel-amazon
Copy link

assign it to me

@github-project-automation github-project-automation bot moved this to Planned work items in OpenSearch Roadmap May 31, 2024
@rayshrey rayshrey added the v2.16.0 Issues and PRs related to version 2.16.0 label Jul 10, 2024
@getsaurabh02 getsaurabh02 added the Roadmap:Search Project-wide roadmap label label Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or improvement to existing feature or request Roadmap:Search Project-wide roadmap label Storage:Remote v2.16.0 Issues and PRs related to version 2.16.0
Projects
Status: New
Status: 🆕 New
Status: Release v2.16 (7/23/24)
Development

Successfully merging a pull request may close this issue.

5 participants