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

Anoop Sam John commented on HBASE-24753:
----------------------------------------

Thanks Nick... Ya even what he mentioned also possible.  Clone a cluster.  The 
drop and recreate the cluster based on saved data is a very common thing.  
HBase always use(d) a FS like HDFS or cloud for storing any persistent data.  
This is really great for cloud cases.  Any system which deal with local storage 
(replicated and raft kind of consensus), wont be easy to make it to work in 
cloud.
bq.And even for now, it is not safe to just restart a new cluster with data on 
HDFS but no data on zookeeper. 
Duo, my concern was not on avoid zk usage and all HM have own consensus for 
leader election (As what the jira title says).  My worry was on the line which 
says move the root table data (meta as of today) away from storage but to local 
and HM handle it in special way.   


> HA masters based on raft
> ------------------------
>
>                 Key: HBASE-24753
>                 URL: https://issues.apache.org/jira/browse/HBASE-24753
>             Project: HBase
>          Issue Type: New Feature
>          Components: master
>            Reporter: Duo Zhang
>            Priority: Major
>
> For better availability, for moving bootstrap information from zookeeper to 
> our own service so finally we could remove the dependency on zookeeper 
> completely.
> This has been in my mind for a long time, and since the there is a dicussion 
> in HBASE-11288 about how to storing root table, and also in HBASE-24749, we 
> want to have better performance on a filesystem can not support list and 
> rename well, where requires a storage engine at the bottom to store the 
> storefiles information for meta table, I think it is the time to throw this 
> idea out.
> The basic solution is to build a raft group to store the bootstrap 
> information, for now it is cluster id(it is on the file system already?) and 
> the root table. For region servers they will always go to the leader to ask 
> for the information so they can always see the newest data, and for client, 
> we enable 'follower read', to reduce the load of the leader(and there are 
> some solutions to even let 'follower read' to always get the newest data in 
> raft).
> With this solution in place, as long as root table will not be in a format of 
> region(we could just use rocksdb to store it locally), the cyclic dependency 
> in HBASE-24749 has also been solved, as we do not need to find a place to 
> store the storefiles information for root table any more.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to