You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today even though a vttablet can restore backups take from different backup engines, we can't change which backup engine we want to use unless we have tablets with different configuration in the same shard or changing it and restarting.
I would propose the following:
adding a field on the Backup() call to allow to pass which backup engine to use, so users can have all the flags and define a default backup engine, but are still able to override which backup engine to use in the Backup() call
adding a field on the RestoreFromBackup() call so backups from certain backup engines can be ignored when a tablet either starts for the first time or when received via its tabletamanger API`.
Use Case(s)
This will be interesting specially in combination with #16294 as it will allow for the particular scenario of being able to take both physical and logical backups, but always restoring physical backups by default. We would still be able to target a specific backup to be restored via and API call via its timestamp.
The text was updated successfully, but these errors were encountered:
Feature Description
Today even though a
vttablet
can restore backups take from different backup engines, we can't change which backup engine we want to use unless we have tablets with different configuration in the same shard or changing it and restarting.I would propose the following:
Backup()
call to allow to pass which backup engine to use, so users can have all the flags and define a default backup engine, but are still able to override which backup engine to use in theBackup()
callRestoreFromBackup()
call so backups from certain backup engines can be ignored when a tablet either starts for the first time or when received via itstabletamanger
API`.Use Case(s)
This will be interesting specially in combination with #16294 as it will allow for the particular scenario of being able to take both physical and logical backups, but always restoring physical backups by default. We would still be able to target a specific backup to be restored via and API call via its timestamp.
The text was updated successfully, but these errors were encountered: