feat(storage): reset to the latest committed epoch in recovery #14923
Conversation
|
Any context on why we need this? |
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 9425213 | Triggered | Generic Password | afc7c19 | ci/scripts/regress-test.sh | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
I just updated the PR description. In short, with this PR we can have two benefits.
|
| self.reset_compute_nodes(&info).await.inspect_err(|err| { | ||
| warn!(error = %err.as_report(), "reset compute nodes failed"); | ||
| })?; | ||
| self.reset_compute_nodes(&info, prev_epoch.value().0) |
There was a problem hiding this comment.
In order for this PR to work, we need to ensure that prev_epoch == latest MCE. Currently this is guaranteed because the prev_epoch is get from self.context.hummock_manager.latest_snapshot().committed_epoch before calling fn recovery.
How about making it more explicitly by getting self.hummock_manager.latest_snapshot().committed_epoch inside the implementation of fn recovery?
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Previously in storage
clear_shared_buffer, we only reset the storage the local max committed epoch. However, it is possible that during recovery the global committed epoch has a greater max committed epoch, and in recovery we have to make an extra wait_epoch_committed rpc to wait for the new version update.In this PR, we change to wait for the local max committed epoch to bump up to the global max committed epoch in the
clear_shared_bufferso that we don't have to send the extrawait_epoch_committed. When we handle the clear event, the cache refiller will drain its pending version update immediately and apply to the current version to try to bump up the local committed epoch to the global one. If the local committed epoch has not reach the global one after the pending version update have been applied, it will keep waiting for further notification of version update and applying the version update until the local committed epoch reach the global one.Major changes in this PR:
prev_epochin theforce_stop_actorsrpc and pass it all the way down to where we actually handle the storage clear in event handler.prev_epochparameter in theclear_shared_buffer, and change its return type fromStorageResult<()>to()Checklist
./risedev check(or alias,./risedev c)Documentation
Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.