You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by GitBox <gi...@apache.org> on 2020/05/01 16:22:44 UTC

[GitHub] [hbase] saintstack edited a comment on pull request #1613: HBASE-24273 HBCK's "Orphan Regions on FileSystem" reports regions wit…

saintstack edited a comment on pull request #1613:
URL: https://github.com/apache/hbase/pull/1613#issuecomment-622445584


   > There seems to be 3 sources of regions: FS, hbase:meta and in-memory. All of them need to be in sync, but what is the source of truth? Is it possible that the region is not in hbase:meta but is in in-memory state regionInfoMap? Could that be a good thing to validate in hbck?
   
   <ideal>Source of truth is Master in-memory. It has most up-to-date, comprehensive state. It effects change. Changes to state are orchestrated by the Master via the Procedures system. Procedures record intention and steps-taken in the Procedure store. When pertinent (changes that processes other-than master need to know of), Procedures publish state changes to hbase:meta (and for some state mostly internal to the cluster, to zk).</ideal>
   
   On crash, Master re-loads from persistent stores -- hbase:meta and the Procedure store -- and reconstructs the before-crash state.
   
   (Note added AFTER review and I'm reminded of what this patch is about)
   
   My BS above is high-level picture of how things are supposed to work... answering Andrey's question. What is going on in here is a mis-Reporting by HBCK Report of resources that are for GC after references are let-go.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org