[
https://issues.apache.org/jira/browse/HBASE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865038#comment-13865038
]
Feng Honghua commented on HBASE-10295:
--------------------------------------
Another HBase internal system table (similar to meta table) is a good choice
for storing replication zk node information, but lacking the zk's inherent
watch/notification mechanism which is essential for the 'client change
replication status(such as peer-state / add peer), regionservers listens and
gets notification for such status and perform accordingly(such as disable a
peer / add a new peer thread)' communication pattern...
No clear plan for now, but I'll spend some time these days to figure out a
draft design for discussion and brainstorming first, any opinion/suggestion is
welcome :-)
And change the title of this jira to make it more general and match its
intention better. [~techbuddy01] :-)
> 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: Feng Honghua
> Assignee: Feng Honghua
> 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 theme.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
