-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Implement the "put-and-verify" lock for external storage. #56523
Comments
I'm not that familiar with BR, can you please clearify some description to help me understand
migrating WHO to a new version? you mean converting a backup stored in S3 to format of another version?
you mean read/write S3 backup at same time?
the storage is the external storage, such as s3 right? |
@D3Hunter The "storage" should be "backup storage", i.e. the set of files generated by log backup. Let me clarify this. "Migration" is an atomic operation that applies to the "stabilized" backup storage (a brief reference here, after applying a "migration", the "stabilized" backup storage goes to a new version. |
redefine |
Enhancement
Background
Sometimes, we need to control concurrency access to the same backup archive, like:
But external storage locking isn't trivial. Simply putting a lock file isn't safe enough: because after checking there isn't such a lock file, another one may write it immediately. Object locks provide stronger consistency, but also require extra configuration and permissions.
We can use a "put-and-verify" lock to lock the storage, in detail, a locker need to implement this interface:
Then we lock the storage by:
Prefix()
.Prefix()
.Verify()
returns no error, put theContent()
to thePrefix()
, without suffix, then remove the intention file.The text was updated successfully, but these errors were encountered: