You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After switching our application to use a cluster-mode redis setup, we discovered that (nearly) all reads to replicas were being redirected to the primary instance. Our application is an API, running in puma with multiple workers (ie. multiple forked processes).
After reviewing the library code, our current theory is that after forking the connection is forced to be re-established because of the process ID change (code). However, because the READONLY command is only sent when the client is initially created, the new connection is not in the correct state to allow for read only commands.
A potential fix for this would be to introduce a new Connector implementation for cluster mode clients that sends the READONLY command after connection.
The text was updated successfully, but these errors were encountered:
@byroot I deployed with ae80708 and everything looks good, no more MOVED errors reported by our telemetry and the number of reads on the primary instance is near-zero.
After switching our application to use a cluster-mode redis setup, we discovered that (nearly) all reads to replicas were being redirected to the primary instance. Our application is an API, running in puma with multiple workers (ie. multiple forked processes).
After reviewing the library code, our current theory is that after forking the connection is forced to be re-established because of the process ID change (code). However, because the
READONLY
command is only sent when the client is initially created, the new connection is not in the correct state to allow for read only commands.A potential fix for this would be to introduce a new
Connector
implementation for cluster mode clients that sends theREADONLY
command after connection.The text was updated successfully, but these errors were encountered: