Skip to content

Conversation

@git-hulk
Copy link
Member

Currently, the pre_fullsync_cb will stop the task runner and set the DB loading status to yes, but it didn't resume those states. This will cause the server to run in restoring status until success in resyncing from the master. To fix this, we need to call the post_fullsync_cb to resume those statuses before restarting full sync.

This PR also uses try_lock to allow the replication thread to be stopped while preparing the restore db.

This closes #2511

Currently, the `pre_fullsync_cb` will stop the task runner and set the
db loading status to yes, but it didn't resume those states. And will
cause the server running in restoring status until success to resync
from master. To fix this, we need to call the `post_fullsync_cb` to
resume those status before restarting full sync.

This PR also uses try_lock to allow to stop the replication thread while
preparing the restore db.
@git-hulk git-hulk merged commit f402be0 into apache:unstable Sep 21, 2024
@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Potential unclear to the temporary dictionary of db while restoring

2 participants