Dgraph-js does not offer graceful way to failover client endpoints/stubs

[MichelDiz]

@savearray2

I currently have a geographically distributed Dgraph cluster over several continents.

Interesting, are you using a single cluster across continents or they are all individuals clusters per continent? if so, can you share your experience with this? seems complicated to deal. As Dgraph treats each node part of a single structure. And perhaps the idea of upgrading “parts” of the cluster can be dangerous if a single breaking thing is added as a feature.

That’s a kind of experience that others might like to read. For example this experience Transitioning from a Relational DB to a Graph DB

@savearray2

Will automatically attempt to send query/mutations to other servers if one server is deemed unavailable, and will only fail if all servers are unreachable.

Dgraph does this internally. It talks to all nodes and “keep in touch” to see who he can count on. Also, the Alphas now supports multiple zeros. It means if your main zero is down, it could try to reach others to keep the cluster healthy.

About this, on the client-side. I had commented this internally some time ago. Following my own bias, I think this is an important behave, not just for possible overseas configurations.

My idea was something like

const clientStub = new dgraph.DgraphClientStub(
  ["localhost:9080", 
   "localhost:9081", 
   "localhost:9082", 
   "localhost:9083", 
   "localhost:9084", 
   "localhost:9085"],
  grpc.credentials.createInsecure(),
);

@savearray2

Prioritizes certain servers for queries/mutations, and only attempts to contact other servers if the prioritized servers are unavailable. This will reduce round-trip time lag when dealing with various geographically disparate regions.

Dgraph does it internally. The first Alpha you hit, will try to reach other Alphas, and the first one who responded will be who serves. If you need to know how it works check this video out https://www.youtube.com/watch?v=Bg4rlmabevM&t=2s

@savearray2

But from a quick reading of the source code, it seems that the client then uses a round-robin approach to choose which stub to use. If a stub endpoint is unreachable, the given query/mutation fails, and the client does not automatically failover to another stub. Please let me know if this understanding is incorrect.

I’m not sure, but he should support it. For example, Liveloader, is able to receive multiple Alphas addresses separated by comma and it will connect to all and send mutations to them. This pattern should be possible in the client javascript.

I mean, you should be able to create a “liveloader” in JS and have the same behavior it has in the golang version. But obviously, it wouldn’t have the same performance.