I believe you are able to get away with just altering the keyspace to include both DC's even before the DC exists, and then adding your nodes to that new DC using the algorithm. Note you'll probably want to take the opportunity to reduce the number of vnodes to something reasonable. Based off memory from previous testing you can get a good token balance with 16 vnodes if you have at least 6 nodes per rack (with RF=3 and 3 racks).
On 16 January 2018 at 16:02, Oleksandr Shulgin <oleksandr.shul...@zalando.de > wrote: > On Tue, Jan 16, 2018 at 4:16 PM, Alexander Dejanovski < > a...@thelastpickle.com> wrote: > >> Hi Oleksandr, >> >> if bootstrap is disabled, it will only skip the streaming phase but will >> still go through token allocation and thus should use the new algorithm. >> The algorithm won't try to spread data based on size on disk but it will >> try to spread token ownership as evenly as possible. >> >> The problem you'll run into is that ownership for a specific keyspace >> will be null as long as the replication strategy isn't updated to create >> replicas on the new DC. >> Quickly thinking would make me do the following : >> >> - Create enough nodes in the new DC to match the target replication >> factor >> - Alter the replication strategy to add the target number of replicas >> in the new DC (they will start getting writes, and hopefully you've >> already >> segregated reads) >> - Continue adding nodes in the new DC (with auto_bootstrap = false), >> specifying the right keyspace to optimize token allocations >> - Run rebuild on all nodes in the new DC >> >> I honestly never used it but that's my understanding of how it should >> work. >> > > Oh, that's neat. We will try this and see if it helps. > > Thank you! > -- > Alex > >
