[
https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250952#comment-16250952
]
Duo Zhang commented on HBASE-19216:
-----------------------------------
I would like to execute the procedure like this:
1. Execute a AddPeerProcedure.
2. Return several RefreshPeerConfigProcedures as sub procedure which are remote
procedures. And the parent procedure is suspended.
3. For each RefreshPeerConfigProcedure, we will schedule a remote request, and
it will be sent by calling executeProcedure. The procedure will also be
suspended after scheduling the call.
4. We will have a way to wake up the RefreshPeerConfigProcedure and tell it
that the refresh is done on RS(this is the problem here).
5. After all the sub procedure are done, we wake up the AddPeerProcedure.
6. AddPeerProcedure will do some post works(like logging) and finish.
So the decision here is that, executeProcedure should be an asynchronous call,
and the return value is useless. When the procedure is done at RS side, it will
call a method to notify the master?
Thanks.
> Use procedure to execute replication peer related operations
> ------------------------------------------------------------
>
> Key: HBASE-19216
> URL: https://issues.apache.org/jira/browse/HBASE-19216
> Project: HBase
> Issue Type: Improvement
> Reporter: Duo Zhang
>
> 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)
