Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-16653

Backport HBASE-11393 to all branches which support namespace

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 1.0.4, 1.4.0, 1.3.1, 0.98.22, 1.1.7, 1.2.4
    • 1.4.0
    • None
    • None
    • Reviewed
    • Hide
      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.
      Show
      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.

    Description

      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.

      Attachments

        1. HBASE-16653-branch-1-v1.patch
          150 kB
          Guanghao Zhang
        2. HBASE-16653-branch-1-v2.patch
          150 kB
          Guanghao Zhang
        3. HBASE-16653-branch-1-v3.patch
          149 kB
          Guanghao Zhang
        4. HBASE-16653-branch-1-v4.patch
          166 kB
          Guanghao Zhang
        5. HBASE-16653-branch-1-v4.patch
          166 kB
          Guanghao Zhang
        6. HBASE-16653-branch-1-v5.patch
          167 kB
          Guanghao Zhang

        Issue Links

          Activity

            People

              zghao Guanghao Zhang
              zghao Guanghao Zhang
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: