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 ne
All,
HBase submits a report to the ASF board once a quarter, to inform the board
about project health. I'm sending the report to the user@ and dev@ mailing
lists because you are the project, and for transparency. If you have any
questions about the report or the running of the project, you can pos
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
goe
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 escreveu:
> You were thinking something like:
>
> 1. add_peer NEW
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
goe
