Key details

  1. The change applies to Cloud SQL for SQL Server.
  2. Cloud SQL Auth Proxy can now connect through a write endpoint.
  3. Cloud SQL language connectors can also use the write endpoint.
  4. The endpoint tracks the writable primary after failover or switchover.
  5. Write endpoints existed before this release; connector/proxy support is the new capability.
  6. Applications still need to handle interrupted connections during failover.

What builders should take away

  1. Replace hard-coded primary instance addresses with the write endpoint where your Cloud SQL SQL Server architecture supports it.
  2. Test planned switchover with your actual proxy/connector and connection pool before relying on the abstraction in production.
  3. Make transaction retries idempotent where possible; following the new primary does not tell the application whether an interrupted transaction committed.
  4. Avoid caching resolved addresses longer than the supported connection stack expects during failover events.

What changed

On September 4, Google added support for connecting Cloud SQL for SQL Server applications to a write endpoint through the Cloud SQL Auth Proxy and supported language connectors. A write endpoint is a DNS name associated with the writable primary. When a replica failover or switchover changes which instance is primary, Google updates the endpoint so new connections are directed to the new primary. Write endpoints were already available; the material change is that applications using Google’s supported connector/proxy layer can now use that abstraction directly instead of separately discovering or pinning an instance address.

Why it matters

High-availability databases only help if applications can find the new primary reliably. Hard-coded instance endpoints create an extra failure mode during switchover and make connection logic more complicated. Connector support makes the write endpoint a more complete application boundary for Cloud SQL SQL Server. It does not make failover invisible: existing connections can still break and applications need sensible retry behavior, but it reduces the amount of topology knowledge the application must carry.

The connector path can now target the role, not the instance

Cloud SQL Auth Proxy and supported language connectors can be configured with the write-endpoint DNS name. That shifts the connection target from a specific database instance to the current writable role.

Failover changes the primary behind the endpoint

When Cloud SQL promotes a replica during failover or a planned switchover, the write endpoint is redirected to the new primary. New connections using that name can therefore follow the topology change without an application configuration rewrite.

This does not remove normal database failover behavior

A DNS-backed endpoint does not preserve an already-open connection through a primary transition. Applications should still expect transient connection failures and use retry/backoff patterns appropriate to their transaction semantics.

What to watch next

  • Connector-specific guidance on reconnection timing during failover.
  • Expansion of the same write-endpoint integration to other Cloud SQL engines or client paths.
  • Operational data on DNS/update convergence during planned and unplanned transitions.

Still unclear

  • The feature simplifies primary discovery but does not guarantee zero-downtime sessions.
  • Failover experience still depends on application connection pools, DNS behavior and retry logic.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment