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
We’ve had multiple times, on our own infra, that full nodes or the prover database got corrupted, we had to resync to the chain.
This won’t be acceptable on mainnet, what are we gonna do if the sequencer’s database gets corrupted?
Ideally, there should be two different rollback features.
Invoked with a cli arg like so
—start-L2-sync-from L2_HEIGHT —start-L1-sync from L1_HEIGHT
This will make sure everything above certain versions for the 3 databases we have will be deleted.
On startup, we check the latest versions of the 3 databases, and if we detect an anomaly, we prune the “higher” table, and start syncing form “lower” table.
The text was updated successfully, but these errors were encountered:
We’ve had multiple times, on our own infra, that full nodes or the prover database got corrupted, we had to resync to the chain.
This won’t be acceptable on mainnet, what are we gonna do if the sequencer’s database gets corrupted?
Ideally, there should be two different rollback features.
Invoked with a cli arg like so
—start-L2-sync-from L2_HEIGHT —start-L1-sync from L1_HEIGHT
This will make sure everything above certain versions for the 3 databases we have will be deleted.
On startup, we check the latest versions of the 3 databases, and if we detect an anomaly, we prune the “higher” table, and start syncing form “lower” table.
The text was updated successfully, but these errors were encountered: