[
https://issues.apache.org/jira/browse/HBASE-21073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647937#comment-16647937
]
Mike Drob commented on HBASE-21073:
-----------------------------------
{quote}
bq. Going to hack around this by skipping the wait entirely.
Ok. But maybe leave that to a follow-on
{quote}
Gotta do the hack now to make the startup sequencing work, can leave the real
fix for later of course.
{quote}
Would be good to purge this hbck1 assumption of the label 'maintenance mode'.
{quote}
Was thinking more on this... Probably ok to delete it entirely? The old
hbck-maintenance-mode was tracked in ZK with an ephemeral node while the hbck
repairs are ongoing. The new thing I'm making is more of an on/off switch, not
a lock.
Maybe setting it in the Configuration object is not so convenient for operators
though. I guess either a shell command or hbck2 command to do it would be nice?
Maybe as follow on? Working through how hbck repo code interacts with main repo
code is still on my to-do list.
> "Maintenance mode" master
> -------------------------
>
> Key: HBASE-21073
> URL: https://issues.apache.org/jira/browse/HBASE-21073
> Project: HBase
> Issue Type: Sub-task
> Components: amv2, hbck2, master
> Reporter: stack
> Assignee: Mike Drob
> Priority: Major
> Attachments: HBASE-21073.master.001.patch,
> HBASE-21073.master.002.patch, HBASE-21073.master.003.patch
>
>
> Make it so we can bring up a Master in "maintenance mode". This is parse of
> master wal procs but not taking on regionservers. It would be in a state
> where "repair" Procedures could run; e.g. a Procedure that could recover meta
> by looking for meta WALs, splitting them, dropping recovered.edits, and even
> making it so meta is readable. See parent issue for why needed (disaster
> recovery).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
