Yep, that's a better, concise description of what I meant. You could even do #2 after #4, doesn't really matter, as long source cluster is already trying to replicate to the new peer id.
Em qua, 10 de jul de 2019 às 13:03, marjana <mivko...@us.ibm.com> escreveu: > 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 >
