I’ve been evaluating CrateDB and while testing the recovery features noticed that all primary shards ended up being assigned to a single node after simulating node failures:
PROMOTE REPLICA is for resolving selecting a primary shard when CrateDB cannot do it automatically without a potential data loss. It can’t be used to re-assign a primary shard to another node.
What is your motivation for re-assigning the primary shards to another node? For CrateDB it does not matter if all primary nodes are on the same node or on different nodes.
The intent was to evaluate the improvement in write speeds. Since the writes go to the primaries, in theory we should get better performance if the those primaries sit on different nodes.
Will that be the case? or it doesn’t matter in Crate’s case?
As the table is replicated to all nodes and the write operation finishes once it’s written to the primary shard and all replica shards I would assume that it wouldn’t have a significant impact in your case.
CrateDB would likely re-distribute the primary shards if you change the number of replicas (ALTER TABLE test_table SET (number_of_replicas = 1);). You can switch back to 2 replicas afterwards if you want.
Yep, changing the shards caused the primaries to be distributed on the cluster. Thanks @jayeff!
I am running some benchmarks with GO-YCSB to understand Crate’s scaling behaviour and baseline performance for our use case. So far its performed well and we were able to orchestrate the “scale-out” and “scale-in” using terraform without a major hiccup!
