hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-19216) Use procedure to execute replication peer related operations
Date Fri, 17 Nov 2017 07:00:15 GMT

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

stack commented on HBASE-19216:

bq. But I would like to make the reportProcedureDone more general. So procedure id will always
be presented, and also a serialized protobuf message. We can encode the peer id in the protobuf

Yeah. This makes sense. Finding a procedure with a pid would be best -- most general -- but
we don't have a lookup at mo. Let me check it out. And then there suspend is done w/ the ProcedureEvent
which is apart from Procedure (as you say above).

And I like the way you are trying to do a general soln because this 'bus', once open, will
be flooded w/ all sorts of cluster messaging.... 

> 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

View raw message