<p>I have a Redis Cluster <em><strong>(3 master and 3 slaves)</strong></em> running inside a <em><strong>Kubernetes</strong></em> cluster. The cluster is exposed via a <em>Kubenetes-Service (Kube-Service)</em>.</p>
<p>I have my application server connected to the Redis Cluster (using the <em>Kube-Service</em> as the URI) via the Lettuce java client for Redis. I also have the following client options set on the Lettuce connection object:</p>
<pre class="lang-java prettyprint-override"><code>ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
              .enablePeriodicRefresh(Duration.ofMinutes(10))
              .enableAllAdaptiveRefreshTriggers()
              .build();

ClusterClientOptions clusterClientOptions = ClusterClientOptions.builder()
              .topologyRefreshOptions(topologyRefreshOptions)
              .autoReconnect(true)
              .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS)
              .build();
redisClient.setOptions(clusterClientOptions);
</code></pre>
<p>Now when I test this setup by killing one of my Redis master's <em>(pods)</em>, Kubernetes does its job by re-scheduling a new pod. But the new pod has a new IP address and it is never discovered by Lettuce. How does Lettuce handle re-discovery. It seems like the logic above for topology refresh does not do a DNS lookup again for the new IPs.</p>
<p>Is there any samples out there or anyone who have handled this. I have read multiple Github issues on Lettuce itself that doesn't give a clear way as to how it was handled.</p>
<p>Best</p>

<p><em>Courtesy of the first comment on the question above.</em></p>
<p>So I was able to resolve this as follows.</p>
<ul>
<li>The above setup for the client with the given options is good. However, I had to set the <code>disconnectedBehavior</code> to <code>ACCEPT_COMMANDS</code>. This ensured that the client continues to engage with Redis for operations during the fail-over.</li>
<li>As a result of this continuous accepting of operations, for the first READ or WRITE that arrives at the client after the failover had successfully elected a new master, the clister will correctly return the new IP address of the new node. From henceforth the client knows whats the new IP for the slots held by the failed node.</li>
</ul>
<p>This is a lazy approach to reconcile on the next attempt to READ or WRITE. But it works and I believe it's good enough. I am not sure if there are better ways to handle this.</p>
