[
https://issues.apache.org/jira/browse/HBASE-24753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172521#comment-17172521
]
Nick Dimiduk commented on HBASE-24753:
--------------------------------------
bq. Actually, no... It is about HBASE-24286, where the AWS guys want to
redeploy an HBase cluster with the old data on S3 but all new virtual machines
as region server. So I say if you want to do this on cloud, you could also use
EBS.
I see. I would classify HBASE-24286 as an operator error, in the sense that
they are attempting to re-hydrate a cluster from partial state (missing WAL
files/directories)... maybe a bug, except that there's never been (i've never
seen) an explicit design that completely isolates root dir filesystem from
master filesystem. What we're talking about in this JIRA is a design choice
explicitly changing from what was intentionally decided before, intentionally
introducing a persistence dependency on something additional to the root dir on
the shared namespace filesystem.
bq. You could build the storage of the raft store on a HDFS? Or even just on a
dynamodb as it is a just a KV? I do not see any problems here...
Consensus storage on HDFS would resolve the concern I attempted to clarify.
> 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)
