hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Trezzo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7564) [replication] Create interfaces for manipulation of replication state
Date Wed, 24 Apr 2013 16:45:16 GMT

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

Chris Trezzo commented on HBASE-7564:
-------------------------------------

[~saint.ack@gmail.com] Yes, sorry for the delay. I'll post a patch for HBASE-7567 today.
                
> [replication] Create interfaces for manipulation of replication state
> ---------------------------------------------------------------------
>
>                 Key: HBASE-7564
>                 URL: https://issues.apache.org/jira/browse/HBASE-7564
>             Project: HBase
>          Issue Type: Improvement
>          Components: Replication
>            Reporter: Chris Trezzo
>            Assignee: Chris Trezzo
>             Fix For: 0.95.1
>
>         Attachments: ReplicationRefactor.pdf, ReplicationRefactor-v2.pdf
>
>
> Currently ReplicationZookeeper maintains all the zookeeper state for replication. This
makes the class relatively large and slightly confusing. There are three major pieces of zookeeper
state maintained for replication:
> 1. The state of replication (i.e. whether replication is ENABLED or DISABLED on the cluster).
This is held in the state znode.
> 2. The set of slave (or peer) clusters that replication needs to ship edits to. This
is held in the peer znode.
> 3. The replication queues that keep track of which hlog files still need to be replicated.
There is one queue for each replication source/peer cluster pair.
> Splitting each of these three pieces into their own interfaces will separate the implementation
from the operations needed to manipulate replication state. This will allow easier unit testing
of the replication logic and more flexibility for future implementations of how replication
state is stored.
> The plan is to implement these changes as a series of patches (at least one for each
of the three interfaces). The state interface will be first, since it is the most easily separable
from the other two pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message