-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove "slave" haproxy resources #50
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also want to capture some notes in the CHANGELOG informing consumers how upgrading to a version of the operator containing this change could affect their applications.
Co-authored-by: Aaron Kuehler <[email protected]>
Co-authored-by: Aaron Kuehler <[email protected]>
Co-authored-by: Aaron Kuehler <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
📦 🚀 🤖
This PR removes the redis-slave-HAProxy, deeming it unnecessary and potentially dangerous .
Originally, this resource was designed as an endpoint for Redis replication nodes to connect to slave nodes of source cluster.
However, when replicated redis uses this resource, the sentinels on source side detect it as a potential slave for failover scenario. In failover, sentinels mistakenly treat the HAProxy pods as legitimate redis slaves and attempt to promote the HAProxy pod as the next master, as it is impossible to do, sentinels get stuck in a promotion loop.
Workaround is to use redis-slave-service as endpoint on source cluster. This way, when sentinels detect replicated redis as potential master in failover scenario, they will not be able to promote it, because replicated redis node is unreachable for connection and sentinels will
forget
this node.