Sorry, seems I misunderstood your question. only zk configs change for your slave cluster, the hbase slave cluster keep the same.
Considered the steps your list: 1. add_peer NEW_ID 'newZK' 2. disable_peer ORIGINAL_ID 'originalZK'. 3. stop slave hbase. move ZK. 4. start slave hbase. Data starts coming in for NEW_ID peer. 5. drop_peer ORIGINAL_ID I think the main problem is: in step#2, you need to wait until there's almost no lag between source cluster and sink cluster. say if there's a huge lag, and you add new peer in step#1 & disable the peer in step#2. then all hlogs enqueued in peer with ORIGINAL_ID before step#1 won't enqueue in peer NEW_ID again. If you drop the peer ORIGINAL_ID, then your slave cluster will loss that part of data. If it's a very small lag(<1s) when you disable the original peer in step#2, I think you can remove the peer right now. Thanks. On Thu, Jul 11, 2019 at 9:45 AM OpenInx <open...@gmail.com> wrote: > Hi marjana. when you alter to the new replication peer, you only want the > new replication data redirect to > the new slave cluster ? how about the old data in the master cluster ? > is that necessary to migrate to the > new slave cluster also ? In our XiaoMi clusters, when doing the migration > to a new slave cluster. we would > like to do the following: > > 1. add a disabled peer for the new slave cluster (enqueue the newly > written data during the snapshot exporting); > 2. create a snapshot in the source cluster; > 3. export snapshot to the new slave cluster; > 4. enable the disabled peer for new slave cluster; (replicate all the > stuck log to new slave). > 5. remove the original replication peer. > > Hope it will be helpful for you. > > On Wed, Jul 10, 2019 at 8:18 PM marjana <mivko...@us.ibm.com> wrote: > >> You were thinking something like: >> >> 1. add_peer NEW_ID 'newZK' >> 2. disable_peer ORIGINAL_ID 'originalZK'. >> 3. stop slave hbase. move ZK. >> 4. start slave hbase. Data starts coming in for NEW_ID peer. >> 5. drop_peer ORIGINAL_ID >> >> Not sure about drop_peer, if I should do it at the end (in case something >> goes wrong with the ZK move) or after I disable it at step 2. >> Thanks >> >> >> >> >> >> -- >> Sent from: >> http://apache-hbase.679495.n3.nabble.com/HBase-User-f4020416.html >> >
