hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12259) Bring quorum based write ahead log into HBase
Date Fri, 17 Oct 2014 20:24:34 GMT

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

Enis Soztutar commented on HBASE-12259:

It would be good to have quorum writes to the WAL for both intra and inter cluster deployments
natively in hbase (or a thin layer on top). We have already seen some usage of the region
replica feature even without sync writes. This will not only help in write latencies, but
we can also implement proper sync() on local disk more easily.  I would imagine the RAFT library
might be used elsewhere as well for multi-master, etc. 

I think once we have hydrabase opened, we can see how we can bring this in. 

> Bring quorum based write ahead log into HBase
> ---------------------------------------------
>                 Key: HBASE-12259
>                 URL: https://issues.apache.org/jira/browse/HBASE-12259
>             Project: HBase
>          Issue Type: Improvement
>          Components: wal
>    Affects Versions: 2.0.0
>            Reporter: Elliott Clark
> HydraBase ( https://code.facebook.com/posts/321111638043166/hydrabase-the-evolution-of-hbase-facebook/
) Facebook's implementation of HBase with Raft for consensus will be going open source shortly.
We should pull in the parts of that fb-0.89 based implementation, and offer it as a feature
in whatever next major release is next up. Right now the Hydrabase code base isn't ready to
be released into the wild; it should be ready soon ( for some definition of soon).
> Since Hydrabase is based upon 0.89 most of the code is not directly applicable. So lots
of work will probably need to be done in a feature branch before a merge vote.
> Is this something that's wanted?
> Is there anything clean up that needs to be done before the log implementation is able
to be replaced like this?
> What's our story with upgrading to this? Are we ok with requiring down time ?

This message was sent by Atlassian JIRA

View raw message