Multiple endpoints configuration

[kulku]

We have an active-active HA configuration enterprise RedisLabs set up in production, with realtime replication between the primary and the secondary clusters. We are specifying the PROD endpoint as the endpoint#1 and the fallback endpoint as endpoint #2 in the endpoints collection via configuration.

1. Are we good to assume that the Tie-Beaker policy picks the first endpoint (endpoint#1), when picking the master?
2. We ran a few tests and see that the values are written to the first database. (not both). Just wanted to know if we would run into gotchas. We don't see the need to use TwemProxy, with the set up we have in production.

Appreciate feedback from the SMEs here.

Thank you.

-----documentation-----
Tiebreakers and Configuration Change Announcements
Normally StackExchange.Redis will resolve master/replica nodes automatically. However, if you are not using a management tool such as redis-sentinel or redis cluster, there is a chance that occasionally you will get multiple master nodes (for example, while resetting a node for maintenance it may reappear on the network as a master). To help with this, StackExchange.Redis can use the notion of a tie-breaker - which is only used when multiple masters are detected (not including redis cluster, where multiple masters are expected). For compatibility with BookSleeve, this defaults to the key named "__Booksleeve_TieBreak" (always in database 0). This is used as a crude voting mechanism to help determine the preferred master, so that work is routed correctly.

Likewise, when the configuration is changed (especially the master/replica configuration), it will be important for connected instances to make themselves aware of the new situation (via INFO, CONFIG, etc - where available). StackExchange.Redis does this by automatically subscribing to a pub/sub channel upon which such notifications may be sent. For similar reasons, this defaults to "__Booksleeve_MasterChanged".

Both options can be customized or disabled (set to ""), via the .ConfigurationChannel and .TieBreaker configuration properties.

These settings are also used by the IServer.MakeMaster() method, which can set the tie-breaker in the database and broadcast the configuration change message. The configuration message can also be used separately to master/replica changes simply to request all nodes to refresh their configurations, via the ConnectionMultiplexer.PublishReconfigure method.

[mgravell]

No, I do not think it is safe to assume that the first would be just just by being the first; not least, any network blip could make it pick the other. I'm open to suggestion on what the correct behaviour should be in active-active, but: it isn't one where we have specific well-defined rules currently.

[kulku]

Thank you @mgravell, for your prompt response. Much appreciated.

[kulku]

I am marking this issue closed, based on the response received from @mgravell