[
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 can change the table-cfs znode directly by append_peer_tableCFs
or remove_peer_tableCFs. Because the new server will read table-cfs config from
replication peer znode. So it doesn't change the replication behavior.
The old client can't change the replication peer znode directly if the peer has
table-cfs config. Because the old client will wirte a new PB object without
table-cfs field to zk directly. Then the new server can't read table-cfs
config, the replication behavior will be wrong.
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 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.
> 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)
