hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toshihiro Suzuki <brfrn...@apache.org>
Subject Re: [DISCUSS] Direction of HBCK2
Date Tue, 28 May 2019 23:55:37 GMT
Hi Josh,

Thank you for the explanation. I agree with the direction for HBCK2.

The problem I wanted to tell you in the Jira is that until we implement the
features
you mentioned, we don't have any direct way how to fix holes and overlaps.
The holes and overlaps can be created by bugs or operation errors, so I
think we
should be able to fix these issues.

I thought OfflineMetaRepair could be a workaround for the issues until we
implement
the features of HBCK2.

Regards,
Toshi


On Tue, May 28, 2019 at 9:12 AM Josh Elser <elserj@apache.org> wrote:

> Context: https://issues.apache.org/jira/browse/HBASE-21665
>
> I left a comment on the above issue about what I thought good things to
> build into HBCK2 would be -- a focus on specific "primitive" operations
> that an admin/operator could use to help repair an otherwise broken
> HBase installation. Some examples I had in my head were:
>
> * Create an empty region (to plug a hole)
> * Report holes in a region chain
>
> In my head, the difference for HBCK2 was that we want to give folks the
> tools to fix their cluster, but we did not want to own the "just fix
> everything" kind of tool that HBCK1 had become. That problem with HBCK1
> was that it was often difficult/problematic for us to know how to
> correctly fix a problem (the same problem could be corrected in
> different ways).
>
> Andrew had some confusion about this, so I'm not sure if I'm off-base or
> if we're all in agreement on direction and we just need to do a better
> job documenting things. Thanks for keeping me honest either way :)
>
> And just in case it doesn't go without saying, HBCK2 would be something
> that helps fix a system, while we want to always understand the root
> cause of how/why we got into a situation where we needed HBCK2 and also
> address that.
>
> - Josh
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message