[
https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283234#comment-16283234
]
Duo Zhang commented on HBASE-19216:
-----------------------------------
A general framework to execute procedures like this:
1. Do some prepare work
2. Create sub procedures for all or some regionservers.
3. After all the sub procedures done, do some post works and finish.
Modify replication peer, snapshot, flush, compact... Lots of operations can be
modeled in this way I think. But snapshot, flush and compact are
TableProcedure, or ServerProcedure, which hae already been implemented in
MasterProcedureScheduler but modify replication peer is another story. So if
want to make the framework be able to execute something like modify replication
peer, I need to add a new queue type in MasterProcedureScheduler, and it seems
that modify replication peer is the only operation for this type?
Or, maybe I could change my test procedure to a TableProcedure... Anyway, I
think we should implement the feature in a feature branch and after it can
finally serve a real operation in HBase we can merge it back.
Will be back later. 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
> 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)
