[
https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172097#comment-14172097
]
Sean Busbey commented on HBASE-12259:
-------------------------------------
The refactoring working in HBASE-10378 should get finished up first. It
obviates some other WAL clean up tickets and generally provides us with a
cleaner separation of concerns than the current HLog.
There's a simplified roadmap around WAL improvements on that ticket and a patch
from a bit ago. Both should get updated in the next day or so with a version
that I think is ready as a first pass implementation. One of the follow-ons is
getting the WAL related code all into its own module, which I think will help a
lot in getting the recovery side of things better isolated.
> Bring quorum based write ahead log into HBase
> ---------------------------------------------
>
> Key: HBASE-12259
> URL: https://issues.apache.org/jira/browse/HBASE-12259
> Project: HBase
> Issue Type: Bug
> 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
(v6.3.4#6332)
