tommyk
commented
1 year ago this comment won't address the code issue with stale DNS records, but if you are using the helm chart to deploy (and if your not just look at how they do this), you can set the following value to have your replicas broadcast their IP instead of hostnames.
this allowed me to roll all my pods multiple times and an app using go-redis keep finding the new master and being able to connect.
## @param useHostnames Use hostnames internally when announcing replication. If false, the hostname will be resolved to an IP address
##
useHostnames: false # truehth
github-actions[bot]
Hi,
I have a kubedb redis cluster in my kubernetes cluster and I create my go-redis ClusterClient with the Addrs of
[]string{"my-redis.kubedb:6379"}.This works fine until I do a deployment against my redis cluster that results in all nodes getting a new ip address.
When this happens, the loadState function at https://github.com/go-redis/redis/blob/master/cluster.go#L967 doesn't know it needs to re-resolve my-redis.kubedb again and so it never finds my new cluster.
It seems in this function I have the initial address at the start of the list but when https://github.com/go-redis/redis/blob/master/cluster.go#L983 happens it gets a cached node object for that address and because all nodes have new ip addresses, this node is no longer correct and so I get no route to host errors.
For now I'll recreate my client if I start getting no route to host errors, but I was wondering if you had ideas on how we can make the go-redis client able to handle this scenario.