[
https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16290685#comment-16290685
]
Anoop Sam John commented on HBASE-19216:
----------------------------------------
When we have the Remote procedure f/w and informing the RSs, can that take the
peer info also? Again to look at the ZK?
This generic work is very good. We can make use of this in ACL. Now after an
ACL admin op (grant/revoke kind of) , we will inform the same to RSs via the
ZK notify way. The ACL region will write the ACL info into zk and the RSs are
watching this path. Getting notified eventually and reading back latest from zk
and update its cache. Well the eventual way or slowness may be ok. But still
would be good Not to go via zk path. That is why asked whether this can take
some payload also (in ACL case the new ACL permission info). Did not see patch
at all.. Just asking and saying the possible usage of the f/w. Good one Duo.
bq.Another benefit is that, after the change, zk will be mainly used as a
storage, so it will be easy to implement another replication peer storage to
replace zk so that we can reduce the dependency on zk.
Good.
> Implement a general framework to execute remote procedure on RS
> ---------------------------------------------------------------
>
> Key: HBASE-19216
> URL: https://issues.apache.org/jira/browse/HBASE-19216
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2, Replication
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Attachments: HBASE-19216-v1.patch, HBASE-19216.patch,
> HBASE-19216.patch, HBASE-19216.patch
>
>
> When building the basic framework for HBASE-19064, I found that the
> enable/disable peer is built upon the watcher of zk.
> The problem of using watcher is that, you do not know the exact time when all
> RSes in the cluster have done the change, it is a 'eventually done'.
> And for synchronous replication, when changing the state of a replication
> peer, we need to know the exact time as we can only enable read/write after
> that time. So I think we'd better use procedure to do this. Change the flag
> on zk, and then execute a procedure on all RSes to reload the flag from zk.
> Another benefit is that, after the change, zk will be mainly used as a
> storage, so it will be easy to implement another replication peer storage to
> replace zk so that we can reduce the dependency on zk.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
