[
https://issues.apache.org/jira/browse/BOOKKEEPER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459490#comment-13459490
]
Uma Maheswara Rao G commented on BOOKKEEPER-278:
------------------------------------------------
Yes, Ivan. I got your point now.
Auditor should not go till markLedgerUnderreplicated itself once it disabled.
Otherwise it will publish many ledgers even though they started correctly now.
This is because of the calls waiting at markLedgerUnderreplicated.
{quote}
It would be better for the auditor to check is auto recovery is enabled after
seeing a bookie drop, and only build the index, mark the ledgers, if it is
enabled.
{quote}
if it disabled it will just ignore or wait?
I think there might be small race here if we ignore silently BK failure
notifications when it is in disabled state.
ex:
Admin added disable Znode.
- restarted some Bookies
- Before admin enable that Autorecovery, some restarted/fresh BKs failed. Now
they are real failures.
then admin enabled it.
If we ignore the BK failure notifications when it was in disabled state, it may
miss this valid notifications, which may need to process once re-replication
enabled right?
Do you think we have to rebuild complete index once it enabled? or simply we
can queue the calls and process them, once it enabled. Need to check this case.
> Ability to disable auto recovery temporarily
> --------------------------------------------
>
> Key: BOOKKEEPER-278
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-278
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-auto-recovery
> Affects Versions: 4.0.0
> Reporter: Ivan Kelly
> Assignee: Rakesh R
> Fix For: 4.2.0
>
> Attachments: BOOKKEEPER-278.patch
>
>
> Administrators will need to do rolling upgrades of bookies. If auto recovery
> is enabled during a rolling upgrade, there will be a lot of thrashing of
> ledgers as they recovery gets kicked off. Therefore we need a way to
> temporarily disable it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
