[ 
https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283178#comment-16283178
 ] 

Duo Zhang commented on HBASE-19216:
-----------------------------------

I planned to implement a general framework and also a test procedure to show 
that the framework is OK. But finally I found that we have different queues in 
MasterProcedureScheduler, and both of ServerQueue and TableQueue can not 
represent the operations like peer state change, and it is weird to add a 
'test' queue type to it.

So I plan to convert HBASE-19397 to a top level issue, and change the title of 
this issue to 'Master side change of peer state change procedure' and make it a 
sub task, and create another sub task for [~openinx]'s RS side change.

Since the feature can only be implemented after both issues are resolved, I 
plan to create a feature branch HBASE-19397, and merge it back after the two 
sub-tasks are both resolved.

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: 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)

Reply via email to