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