[
https://issues.apache.org/jira/browse/HBASE-21073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647147#comment-16647147
]
stack commented on HBASE-21073:
-------------------------------
bq. All of this work is completely disjoint from the earlier maintenance mode,
which is why I gave it a different name. I didn't look too deeply into what old
maintenance mode did.
Would be good to purge this hbck1 assumption of the label 'maintenance mode'.
bq. Maybe? Limiting the access is more work, and I'm not sure what it gains us.
We'd avoid confused clients thinking the hbase is 'up'.
Can I connect to the Master when in maintenance mode with the shelll? That
would be useful I'd say.
bq. Going to hack around this by skipping the wait entirely.
Ok. But maybe leave that to a follow-on. I was in here a while back convinced
that the hang at this spot an error but after spending some time, put it off as
a 'later'... to be dealt with when we make the startup sequence more sane such
that a Master really can be a RS rather than this fake that we have now.
Thanks [~mdrob]
> "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)
