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
Describe the bug
If we try to open-fence ledgers that have previously been marked as Empty (only possible from a previous fence-out operation) then we might hit a missing ledger (deleted by us; but we crashed before updating metadata). This currently prevents the recovery from proceeding (or even starting).
We should modify the code in one of two ways:
Do not even attempt to open-fence empty ledgers (we are 100% certain they are empty since we only assign that status after a previous recovery that verified they are empty).
Continue as we do now, but if we get a LedgerNotFoundException, simply log a WARN and move on.
Option 2 is preferable since we always attempt to re-verify a previous evaluation vs blindly trusting it.
The text was updated successfully, but these errors were encountered:
Cherry-pick #6030 into r0.9.
Issue 6030: (SegmentStore) Ignoring missing ledgers that were previously marked as Empty. (#6031)
During the BookKeeperLog initialization phase, we are now ignoring ledgers that we cannot open-fence due to them missing but have been previously identified as being Empty.
Signed-off-by: Andrei Paduroiu <andrei.paduroiu@emc.com>
Describe the bug
If we try to open-fence ledgers that have previously been marked as Empty (only possible from a previous fence-out operation) then we might hit a missing ledger (deleted by us; but we crashed before updating metadata). This currently prevents the recovery from proceeding (or even starting).
We should modify the code in one of two ways:
LedgerNotFoundException
, simply log a WARN and move on.Option 2 is preferable since we always attempt to re-verify a previous evaluation vs blindly trusting it.
The text was updated successfully, but these errors were encountered: