[
https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175826#comment-14175826
]
stack commented on HBASE-12259:
-------------------------------
bq. 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.
Agree. Feature branch would be way to go.
bq. Is this something that's wanted?
Sounds good. Lets take a look at what is involved (From what I know of
hydrabase, its a X-DC WAN story.. An in-DC, in-cluster deploy is probably what
we'd be interested in doing first).
bq. Is there anything clean up that needs to be done before the log
implementation is able to be replaced like this?
See Sean's comment above. He is doing nice WAL Interface refactor/cleanup.
Does current hydrabase need more than current WAL API or it just works using
current API w/ the magic going on behind WAL append, sync, close, roll, calls?
bq. What's our story with upgrading to this? Are we ok with requiring down time
?
If downtime, would imply a 2.0 (or 3.0) feature (IMO).
> 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
(v6.3.4#6332)
