IssueTracker

No official word from Google so I'm inclined to weigh in here with the little I do know and suspect. (I obviously don't speak for Google, so grain of salt and all that.)

The focus of the Cloud SQL is minimizing the duration of the downtime windows, and the frequency in which they happen, but not to completely eliminate the possibility of instances ever going down. For that, there is Cloud Spanner, which is arguably the flagship product of GCP and what I suspect GCP uses internally for everything. There's little incentive for them to pour time and resources into making postgres never-down when that is the bread and butter of Spanner, especially when no one is using it internally.

GCP is keenly aware of this issue and I've raised it through as many channels as I could. The occasional update to the metadata here suggests it does get looked at, and I don't envy the product manager that would have to try and explain why this never gets priority to the mob, so maybe it's just best to let this issue rot. Keep adding to the 123 stars, but 30+ comments of "+1" and "we're leaving to X" is probably enough.

For what it's worth, we track outages caused by this database roll, and while they do still happen, year-over-year they are going nothing but down. Breaking updates that take our HA cluster offline seem to happen less, though they do take about the same amount of time to come back up as they always have. We shifted a few downtime-sensitive DB's elsewhere, and as our data got global enough to merit it, have started exploring spanner and its associated price tag more seriously.

As much as I'd love for this to be solved, we've accepted it where we can, and moved on where we couldn't.

Hello Cloud SQL users,

This year, Cloud SQL redesigned our maintenance workflow to reduce maintenance downtime by 80%. Our new workflow utilizes a shared disk failover approach, in which we first update a failover target VM with the maintenance patch while the original is still running. Once the update is complete, we stop the original instance, switch over the disk, failover the IP address, and resume traffic on the updated VM. Typical maintenance downtime per engine is below:

• PostgreSQL - 30 seconds or less

• MySQL - 60 seconds or less

• SQL Server - 120 seconds or less

For more information, you can read our blog on the new maintenance process:

https://cloud.google.com/blog/products/databases/how-cloud-sql-maintenance-works-to-keep-instances-updated

Since the shared disk failover approach has been implemented, we plan to mark this issue tracker ticket as "Fixed" in one week's time. When combining faster maintenance with scheduling controls like maintenance windows and deny maintenance periods, many Cloud SQL customers are no longer impacted by maintenance.

However, for 24/7 business-critical applications that have very high uptime requirements, maintenance may still be disruptive. For these customers, we continue to invest in reducing maintenance downtime. To indicate that your application requires further improvement in mainteance downtime, please star this new issue tracker ticket so we can track interest.

https://issuetracker.google.com/issues/200192156

All the best,

Akhil

Cloud SQL Product Manager