Tie breaker master node with higher latency

Hi

I know this is not the recommended option, but I have a stretched cluster in two DC's with dedicated master-eligible nodes, and a 3rd DC with just one tie-breaker node.

This 3rd datacenter has a higher latency (possibly AWS) while the 2 original DC's have negligible latency.

My undestanding is that the tie-breaker has the same configuration settings that any other master-eligible nodes (master=true, data=false). I'd like to know how this will impact performance of general querying or indexing.

Is there any impact on having the master node far from the data nodes?

How frequently is the communication between the data nodes and its master. Can this affect latency of queries, indexing, etc?

I'm not sure if this master node is very chatty with the data nodes (I guess it will be when deciding where to allocate a primary shard or its replicas, and when any node crashes, but other than that...?)

Is there any foreseable performance impact with this configuration?

Moreover, is there any useful setting to avoid that a tie-breaker actually becomes the master, so it only participates in master election but it's not candidate itself?

EDIT: If I'm not wrong, every node holds the cluster state which tells a node which shard an indexed document needs to go to. Does this mean that latency is not important between the master and the data nodes?

It's important for cluster level operations.
Mapping updates, new indices, node changes etc.

If these time out it can cause larger issues.

2 Likes

@warkolm thanks for your response

My cluster level operations are very unlikely:

  1. Create a daily index
  2. Possibly mapping updates every quarter of a year
  3. Not very frequent node changes (unless they crash or some more nodes are added, that may happen on peak traffic very few times a year).

You can do this, you can also juggle snakes. Doesn't make it a good idea :wink:

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.