[jira] [Comment Edited] (HBASE-18228) HBCK improvements

["Karan Mehta (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063613#comment-16063613 ] 

Karan Mehta edited comment on HBASE-18228 at 6/26/17 7:21 PM:
--------------------------------------------------------------

What should be the granularity of the operation? 
For example, running -fixAssigments or -fixHoles on a table, would run certain steps for the all the regions. Do we need to ask the user for individual step confirmation or for the command as a hole?
The pros are
* More granularity, more power / flexibility to the user

The cons are
* Lot of questions / decisions for user if the table has large number of regions
* Hbck will run in parallel for every regionserver. The messages will be intermingled.
* User might accidentally leave cluster in unhealthy state. For example, if the user decides to fix certain holes vs not fixing some of them in meta. 
* The alternate option is to get user confirmation before every major step, which would help if switches like -repair is used, which internally performs bunch of other steps.

[~jmhsieh] [~lhofhansl] [~apurtell] [~churromorales] Please suggest.


was (Author: karanmehta93):
What should be the granularity of the operation? 
For example, running -fixAssigments or -fixHoles on a table, would run certain steps for the all the regions. Do we need to ask the user for individual step confirmation or for the command as a hole?
The pros are
 - More granularity, more power / flexibility to the user
The cons are
 - Lot of questions / decisions for user if the table has large number of regions
 - Hbck will run in parallel for every regionserver. The messages will be intermingled.
 - User might accidentally leave cluster in unhealthy state. For example, if the user decides to fix certain holes vs not fixing some of them in meta. 

The alternate option is to get user confirmation before every major step, which would help if switches like -repair is used, which internally performs bunch of other steps.

[~jmhsieh] [~lhofhansl] [~apurtell] [~churromorales] Please suggest.

> HBCK improvements
> -----------------
>
>                 Key: HBASE-18228
>                 URL: https://issues.apache.org/jira/browse/HBASE-18228
>             Project: HBase
>          Issue Type: Improvement
>          Components: hbck
>            Reporter: Lars Hofhansl
>            Assignee: Karan Mehta
>            Priority: Critical
>             Fix For: 1.4.0
>
>
> We just had a prod issue and running HBCK the way we did actually causes more problems.
> In part HBCK did stuff we did not expect, in part we had little visibility into what HBCK was doing, and in part the logging was confusing.
> I'm proposing 2 improvements:
> 1. A dry-run mode. Run, and just list what would have been done.
> 2. An interactive mode. Run, and for each action request Y/N user input. So that a user can opt-out of stuff.
> [~jmhsieh], FYI



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)