hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-19543) Abstract a replication storage interface to extract the zk specific code
Date Wed, 20 Dec 2017 13:22:00 GMT

     [ https://issues.apache.org/jira/browse/HBASE-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Duo Zhang updated HBASE-19543:
    Attachment: HBASE-19543-HBASE-19397.patch

Add ReplicationPeerStorage and ReplicationQueueStorage. Introduce a ReplicationPeerManager
to replace the old ReplicationManager.

> Abstract a replication storage interface to extract the zk specific code
> ------------------------------------------------------------------------
>                 Key: HBASE-19543
>                 URL: https://issues.apache.org/jira/browse/HBASE-19543
>             Project: HBase
>          Issue Type: Sub-task
>          Components: proc-v2, Replication
>            Reporter: Duo Zhang
>            Assignee: Duo Zhang
>         Attachments: HBASE-19543-HBASE-19397.patch
> For now, we will do sanity checks at the same time when updating replication peer. But
this is not a safe way for procedure based replication peer modification.
> For the old zk watcher way, the only thing is updating the data on zk, so if the data
is updated and then we crashes, there is no problem.
> For the new procedure way, we need to trigger refresh by ourselves after updating zk.
If we crashes after the updating and before we record the state change of the procedure, we
may fail with IllegalArgumentException when we execute the procedure next time since the data
on zk has already been updated.
> So the current way is to do sanity checks in PRE_PEER_MODIFICATION state, and in UPDATE_STORAGE
state we will not do sanity checks any more, just update(overwrite) the peer storage.

This message was sent by Atlassian JIRA

View raw message