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-10295) Refactor the replication implementation to eliminate permanent zk node
Date Mon, 07 Apr 2014 12:08:14 GMT

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

Enis Soztutar commented on HBASE-10295:

bq. Make Master arbiter for these new system tables – only the master can mod them – and
then add a response on the heartbeat to update regionservers on last edit? Could be as simple
as master just replying w/ timestamp of last edit. 
We should do this as a part of (or using) HBASE-9864. I was thinking of something similar,
where the data is kept in an hbase table as a snapshot + WAL. All transactions will have an
trxid (NO timestamps please). All region servers open a session with a lease, and keep heartbeats
to renew their lease. They send the last seen trxId, and the coordinator replies with the
list of edits that they should apply to their in memory cache. If some reader looses it's
leases, the coordinator (master) invalidates its session (so that there is an upper bound
on the time the edits will be propogated). The coordinator keeps the last seen trxId per session,
so that it can do recreate the snapshot and get rid of write ahead log entries. 

However, astute readers might have noticed that this is indeed similar to zk's own protocol
except that the data is not replicated via ZAB, but via datanode pipelines and hbase.  

> Refactor the replication  implementation to eliminate permanent zk node
> -----------------------------------------------------------------------
>                 Key: HBASE-10295
>                 URL: https://issues.apache.org/jira/browse/HBASE-10295
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication
>            Reporter: Honghua Feng
>             Fix For: 0.99.0
> Though this is a broader and bigger change, it original motivation derives from [HBASE-8751|https://issues.apache.org/jira/browse/HBASE-8751]:
the newly introduced per-peer tableCFs attribute should be treated the same way as the peer-state,
which is a permanent sub-node under peer node but using permanent zk node is deemed as an
incorrect practice. So let's refactor to eliminate the permanent zk node. And the HBASE-8751
can then align its newly introduced per-peer tableCFs attribute with this *correct* implementation

This message was sent by Atlassian JIRA

View raw message