[
https://issues.apache.org/jira/browse/HBASE-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186643#comment-15186643
]
Mikhail Antonov commented on HBASE-15406:
-----------------------------------------
How many such tools we could have in mind, which might require cluster-side
recovery? Any lease recovery for the tool is probably going to be somewhat
bulky/boilerplate, so if we need /want that for more than one tool (do we?)
would be good to avoid doing that just for hbck.
Another way is to try to address it in a cheap way which covers most of
probable issues. May be as I noted above, we can address hitting Ctrl-C by
adding a signal handler (and making sure we intercept any exceptions inside
hbck itself at highest levels to do that recovery). Probability of machine
running scheduled hbck cron jobs getting killed or loosing network is low (we
just need to make sure hbck itself doesn't exit without exception handling).
Probability of admin aborting command and leaving without reading any notices
is higher imho.
> Split / merge switch left disabled after early termination of hbck
> ------------------------------------------------------------------
>
> Key: HBASE-15406
> URL: https://issues.apache.org/jira/browse/HBASE-15406
> Project: HBase
> Issue Type: Bug
> Reporter: Ted Yu
> Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-15406.v1.patch
>
>
> This was what I did on cluster with 1.4.0-SNAPSHOT built Thursday:
> Run 'hbase hbck -disableSplitAndMerge' on gateway node of the cluster
> Terminate hbck early
> Enter hbase shell where I observed:
> {code}
> hbase(main):001:0> splitormerge_enabled 'SPLIT'
> false
> 0 row(s) in 0.3280 seconds
> hbase(main):002:0> splitormerge_enabled 'MERGE'
> false
> 0 row(s) in 0.0070 seconds
> {code}
> Expectation is that the split / merge switches should be restored to default
> value after hbck exits.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
