[
https://issues.apache.org/jira/browse/HBASE-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201495#comment-15201495
]
Heng Chen commented on HBASE-15406:
-----------------------------------
Think about this situation:
1. before the first hbck run, splitAndMerge is true
2. hbck abort, splitAndMerge is false, we will keep the state on zk as
original state, and rerun will restore this state firstly.
3. user uses command set splitAndMerge to be true
4. hbck rerun, first it restore the original state left by first hbck to be
false, then do normal operation (acquire the lock and change the switch). At
the end of hbck, the switch state will be false. But user has set it to be
true.
> 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.patch, HBASE-15406.v1.patch,
> HBASE-15406_v1.patch, test.patch, wip.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)