Database BackupManager #1711
Database BackupManager #1711
Conversation
…rocksdb-backup
| @@ -119,6 +119,10 @@ impl SnapshotManager { | |||
|
|
|||
| Ok(SnapshotManagerIter::new(db_iter, snapshot_iterators)) | |||
| } | |||
|
|
|||
| pub fn get_db_handle(&self) -> Arc<sov_schema_db::DB> { | |||
| self.db.clone() | |||
There was a problem hiding this comment.
It would be nice to see the consequences of returning a Weak ptr here. Just curious
| .or(self.base_path.as_ref()) | ||
| .context("Missing path and no backup_path found in config.")?; | ||
|
|
||
| let l1_lock = self.l1_processing_lock.lock().await; |
There was a problem hiding this comment.
What are these locks for? If we need a FS lock, we can use https://docs.rs/file-lock/latest/file_lock/
There was a problem hiding this comment.
The idea behind the two locks is to make sure the three backups are created in a consistent L1 and L2 state between them.
We hold both locks, start the backup process in a consistent state, then release locks. The node can continue producing block while the backups are made from the same L2/L1 height
There was a problem hiding this comment.
Ok, understood. Do we produce l1 blocks in parallel while producing l2 blocks or we are blocked by l1 production? If we are blocked, then there is no need for 2 mutexes?
There was a problem hiding this comment.
L1 and L2 block productions are independent from each other. The two mutexes are here for the backup manager to hold both locks and have a consistent L1 and L2 height
…rocksdb-backup
|
Holding merge until devops' feedback |
…rocksdb-backup
Description
BackupManagerto backup all databases required by a citrea node.backup_create <path>to create a node backup atpathbackup_validate <path>to validate a node backup atpathbackup_info <path>to get info about backup atpath--restore-db <path>arg to restore a node from a backup atpath.Linked Issues
Depends on #1714Missing