| commit | 79768fee1c28d42f4883eb80c5ab6dd88e38a4f5 | [log] [tgz] |
|---|---|---|
| author | Jack Vanlightly <vanlightly@gmail.com> | Mon Apr 12 11:06:52 2021 -0700 |
| committer | GitHub <noreply@github.com> | Mon Apr 12 11:06:52 2021 -0700 |
| tree | 5003952196405d9c180d3e68eef34ca83f6095e0 | |
| parent | 646e59089bc1fd881eff4cc0fb4070220d23dc86 [diff] |
ISSUE #2615: Fix for invalid ensemble issue during ledger recovery Ensures that only entries of the current ensemble are included in the ledger recovery process, thus avoiding a ledger recovery failure scenario where it tries to append an ensemble with a lower first entry id than the prior ensemble. Descriptions of the changes in this PR: This PR includes a small change in the LedgerRecoveryOp that avoids a scenario where ledger recovery tries to create an invalid ensemble thereby failing. This could cause data unavailability for as long as trigger conditions last. During ledger recovery, only entries of the current ensemble can be included in the read and write back phase. Prior ensembles, if any, are immutable. But it is possible, in a multi-ensemble ledger, for the current ensemble to return an LAC of -1. This then causes the recovery to read entries from prior ensembles and write them back to the current ensemble. This does not cause any data loss, but it is wasteful of both space and time. The main issue is that if an ensemble change occurs when writing back entries, it will try and create a new ensemble with first entry id of 0. This causes an IllegalStateException as there is a check before the CAS metadata op to ensure that the ensemble does not have an entry id lower than an existing ensemble. If a bookie of the current ensemble were to be down, then the ledger would be unrecoverable until it became available again. The solution is that the lowest safe LAC for recovery is: first entry id of current ensemble - 1. ### Changes Change to LedgerRecoveryOp as described above. New unit test in LedgerRecoveryTest2. Master Issue: #2615 Reviewers: Andrey Yegorov, Enrico Olivelli <eolivelli@gmail.com>, Flavio Junqueira This closes #2654 from Vanlightly/fix-invalid-ensemble-change, closes #2615
Apache BookKeeper is a scalable, fault tolerant and low latency storage service optimized for append-only workloads.
It is suitable for being used in following scenarios:
Please visit the Documentation from the project website for more information.
For filing bugs, suggesting improvements, or requesting new features, help us out by opening a Github issue or opening an Apache jira.
Subscribe or mail the user@bookkeeper.apache.org list - Ask questions, find answers, and also help other users.
Subscribe or mail the dev@bookkeeper.apache.org list - Join development discussions, propose new ideas and connect with contributors.
Join us on Slack - This is the most immediate way to connect with Apache BookKeeper committers and contributors.
We feel that a welcoming open community is important and welcome contributions.
See Developer Setup to get your local environment setup.
Take a look at our open issues: JIRA Issues Github Issues.
Review our coding style and follow our pull requests to learn about our conventions.
Make your changes according to our contribution guide.