I’m trying to figure out how to set up replicas across availability zones.
It seems to me that setting the --replicas flag automatically determines what group a node is in.
Ideally, replicas would be spread across availability zones so that if a zone goes down the replica in another zone is still running. From what I can tell, if I have 6 nodes with replicas set to 3 (2 groups), it is possible for all 3 replicas of a single group to end up in a single availability zone.
Is there any mechanism for pinning a group to a node?
Is there some way an alpha node is be able to specify to the zeros what zone it’s in?
The --replicas flag configures the max number of Alpha replicas per group.
You can set up your instances to be spread out across availability zones (AZs). Typically, you can run one Dgraph instance (a Dgraph Alpha or Dgraph Zero) per node, and these nodes can be spread across AZs. Running Dgraph Alphas on separate nodes would better utilize the machine resources.
Zone and node placement are outside of the responsibility of Dgraph itself. You’d configure that in whichever way you manage your instances (e.g., Kubernetes’s node affinity rules to schedule pods to be in the same or different AZs).
If I am running 6 instances with the replicas flag set to 3, how can I guarantee that all the instances of a single group are not located in a single availability zone? From what I understand, the groups are assigned automatically.
Is there a command line flag that I can pass when starting up the Dgraph Alpha to specify it should belong to a specific group? I can use Kubernetes node affinity rules, but I still need to be able to tell a Dgraph Alpha instance what groups it should hold to ensure all replicas for a single group do not end up in a single availability zone.