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

Move replication peer storage from zookeeper to other storage systems

    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.6.0, 3.0.0-alpha-4
    • Replication
    • None
    • Reviewed
    • Hide
      Introduced a ‘hbase.replication.peer.storage.impl’ config to support using different replication peer storage implementation. For now there are two built in implementations, ‘zookeeper’ and ‘filesystem’. The default implementation is still zookeeper as users do not need to specify this configuration in the past so if we change the default implementation, after upgrading, the implementation will be changed and cause data loss.
      For filesystem replication peer storage, there is a config ‘hbase.replication.peers.directory’ for specifying the directory. The value is relative to the hbase root directory and the default value is ‘peers’.
      We also implemented a tool for migrating replication peer data across different replication peer storage implementations. Use

      ./bin/hbase copyreppeers <SRC_REPLICATION_PEER_STORAGE> <DST_REPLICATION_PEER_STORAGE>

      to copy the replication peer data. Notice that we will not delete the data in the src storage, for supporting online migration. You need to delete the old storage manually after copying.
      For supporting online migration, we implemented a shell command to disable replication peer modification. Use

      peer_modification_switch <disableOrEnable>, <drainProcedures>

      to enable or disable replication peer modification. The `drainProcedures` parameter means whether you want to wait until all the existing peer modification procedures to finish before returning when disabling peer modification. We also implemented a shell command ‘peer_modification_enabled’ to query whether replication peer modification is enabled currently.

      So when you want to migrate replication peer storage online, you can disable replication peer modification first, then run the copyreppeers tool to copy the replication data from the old storage to new storage, then update all the config files in the cluster, then trigger a online configuration update to load the configuration.
      Show
      Introduced a ‘hbase.replication.peer.storage.impl’ config to support using different replication peer storage implementation. For now there are two built in implementations, ‘zookeeper’ and ‘filesystem’. The default implementation is still zookeeper as users do not need to specify this configuration in the past so if we change the default implementation, after upgrading, the implementation will be changed and cause data loss. For filesystem replication peer storage, there is a config ‘hbase.replication.peers.directory’ for specifying the directory. The value is relative to the hbase root directory and the default value is ‘peers’. We also implemented a tool for migrating replication peer data across different replication peer storage implementations. Use ./bin/hbase copyreppeers <SRC_REPLICATION_PEER_STORAGE> <DST_REPLICATION_PEER_STORAGE> to copy the replication peer data. Notice that we will not delete the data in the src storage, for supporting online migration. You need to delete the old storage manually after copying. For supporting online migration, we implemented a shell command to disable replication peer modification. Use peer_modification_switch <disableOrEnable>, <drainProcedures> to enable or disable replication peer modification. The `drainProcedures` parameter means whether you want to wait until all the existing peer modification procedures to finish before returning when disabling peer modification. We also implemented a shell command ‘peer_modification_enabled’ to query whether replication peer modification is enabled currently. So when you want to migrate replication peer storage online, you can disable replication peer modification first, then run the copyreppeers tool to copy the replication data from the old storage to new storage, then update all the config files in the cluster, then trigger a online configuration update to load the configuration.

    Description

      This is a more specific issue based on the works which are already done in HBASE-15867.

      There are several candidates for storing replication peer.

      1. A new family of master local region
      2. On FileSystem
      3. A new family of hbase:meta

      Either choice has pros and cons. We need to decide which way to go first.

      Attachments

        Issue Links

          Activity

            People

              zhangduo Duo Zhang
              zhangduo Duo Zhang
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: