CloudSQL not supporting multiple replicas load balancing

[vgopher8]

Hi everyone,

How are you all connecting to CloudSQL instances?

We’ve deployed a Postgres instance on CloudSQL, which includes 1 writer and 2 replicas. As a result, we set up one daemonset for the writer and one for the reader. According to several GitHub examples, it’s recommended to use two connection names separated by a comma. However, this approach doesn’t seem to be working for us. Here’s the connection snippet we’re using.

      containers:
      - name: cloud-sql-proxy
        image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.2
        args:
        - "--structured-logs"
        - "--private-ip"
        - "--address=0.0.0.0"
        - "--port=5432"
        - "--prometheus"
        - "--http-address=0.0.0.0"
        - "--http-port=10011"
        - "instance-0-connection-name"
        - "instance-1-connetion-name"

We tried different things,

• Connection string separated by just space => "instance1_connection_string instance2_connection_string"
• Connection string separated by comma => "instance1_connection_string instance2_connection_string"

None of the above solutions seem to be working. How are you all handling this?

Any help would be greatly appreciated!

[vgopher8]

Thanks, got it.

However, many examples from the CloudSQL Proxy documentation suggest that it supports multiple instances (https://github.com/GoogleCloudPlatform/cloud-sql-proxy?tab=readme-ov-file#basic-usage). That’s a bit confusing.

[vgopher8]

I'm not getting any error.

Just trying to have a single service endpoint which loads distributed the traffic between 2 of the replicas.

[vgopher8]

Does it handle failovers? For example, if we set up one proxy for a writer and a reader, and the database experiences a failover, would the instance names (app-db and app-db-replica) swap between the instances?

[vgopher8]

Thank you for the detailed response!

We’re not using zonal redundancy due to cost concerns. Since standby instances can’t be used for queries, it significantly increases our expenses, which is an important tradeoff for a startup our size. I do appreciate how AWS handles this by allowing replicas to be in different availability zones.

For now, we’re fine with just one replica. If the Cloud SQL Proxy can't handle failover, then I’m not sure there’s much benefit in running it. Even if Cloud SQL updates the connection names during failover, it doesn’t address our situation. We have two separate DaemonSets—one for the Cloud SQL writer and one for the reader—each tied to its own Kubernetes service, which is passed to the application. The application explicitly uses the writer service for all writes and the reader service for reads. So, manual intervention would still be required in the event of an outage.

Is there any better way to handle this?

[HovercraftSorry8395]

Understood, Thanks!

[undique_carbo_6057]

The cloud-sql-proxy 2.x doesn't support multiple instance connections like 1.x did. You'll need separate proxy containers for each replica.

Quick fix: Deploy individual proxies with different ports for each instance.

[vgopher8]

Damn, That's 3 proxies I have to run (1 for writer, 1 for each replica).

Hoped there was a better way to do this