[
https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16290694#comment-16290694
]
Duo Zhang commented on HBASE-19216:
-----------------------------------
{quote}
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?
{quote}
For modifying peer, my design is to update the external storage first, and then
tell the RS to fetch the new config from that storage.
But at least I need to tell the RS the peer id so there is a binary parameter
which can be used to carry some information. You can serialize a protobuf
message at master side and deserialize it at RS side to get what you want.
Thanks.
> 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)
