hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guanghao Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-16653) Backport HBASE-11393 to all branches which support namespace
Date Tue, 31 Oct 2017 01:39:00 GMT

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

Guanghao Zhang updated HBASE-16653:
-----------------------------------
    Release Note: 
During HBASE-11393, we have done two things:
1.  unify tableCFs with peerConfig
2.  Fix ns not support issue for replication. 

This issue is to backport it to branch-1

How to rolling update if the replication peer have old table-cfs string config? Due to we
modify proto object of ReplicationPeerConfig (add tableCFs field), so when we do rolling update,
we have to update original ReplicationPeerConfig data on ZK firstly.
1. Make sure the master have the permission to modify replication peer znode.
2. Disable the replication peer.
3. Rolling update master first. The master will copy the table-cfs config from old table-cfs
znode and add it to the new proto object of ReplicationPeerConfig.
4. Rolling update regionservers.
5. Enable the replication peer.

If you can't change the replication peer znode permission, you can use the TableCFsUpdater
tool to copy the table-cfs config.
1. Disable the replication peer.
2. bin/hbase org.apache.hadoop.hbase.replication.master.TableCFsUpdater update
3. Rolling update master and regionservers.
4. Enable the replication peer.

Notes:
We have to wait for the rolling update completed if we want change one replication peer's
table-cfs config.
The old client change the table-cfs znode directly not the replication peer znode. And the
new server will read table-cfs config from replication peer znode. So it is ok for old client
to change the old table-cfs znode directly but it will not work.
 


  was:
During HBASE-11393, we have done two things:
1.  unify tableCFs with peerConfig
2.  Fix ns not support issue for replication. 

This issue is to backport it to branch-1

How to rolling update if the replication peer have old table-cfs string config? Due to we
modify proto object of ReplicationPeerConfig (add tableCFs field), so when we do rolling update,
we have to update original ReplicationPeerConfig data on ZK firstly.
1. Make sure the master have the permission to modify replication peer znode.
2. Disable the replication peer.
3. Rolling update master first. The master will update the table-cfs config from string to
PB.
4. Rolling update regionservers.
5. Enable the replication peer.

Notes:
Due to we modify proto object of ReplicationPeerConfig (add tableCFs field), so when we do
rolling update, we have to update original ReplicationPeerConfig data on ZK firstly.
This means during rolling update, if one peer with namespace added, this peer replication
on old regionserver could not work. We have to wait for the rolling update completed. 
 



> Backport HBASE-11393 to all branches which support namespace
> ------------------------------------------------------------
>
>                 Key: HBASE-16653
>                 URL: https://issues.apache.org/jira/browse/HBASE-16653
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.0.4, 1.4.0, 1.3.1, 0.98.22, 1.1.7, 1.2.4
>            Reporter: Guanghao Zhang
>            Assignee: Guanghao Zhang
>             Fix For: 1.4.0
>
>         Attachments: HBASE-16653-branch-1-v1.patch, HBASE-16653-branch-1-v2.patch, HBASE-16653-branch-1-v3.patch,
HBASE-16653-branch-1-v4.patch, HBASE-16653-branch-1-v4.patch, HBASE-16653-branch-1-v5.patch
>
>
> As HBASE-11386 mentioned, the parse code about replication table-cfs config will be wrong
when table name contains namespace and we can only config the default namespace's tables in
the peer. It is a bug for all branches which support namespace. HBASE-11393 resolved this
by use a pb object but it was only merged to master branch. Other branches still have this
problem. I thought we should fix this bug in all branches which support namespace.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message