hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karan Mehta (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-18228) HBCK improvements
Date Mon, 26 Jun 2017 19:23:00 GMT

    [ 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:22 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)

Mime
View raw message