-1

Problem: Cloud SQL instances run indefinitely and are monetarily expensive to host.

Goal: Save money while not compromising on database availability.

It has been almost four years and Google Cloud has not fulfilled this feature request that has already been implemented on AWS with their Aurora RDS.

Since it does not seem that on demand Cloud SQL that auto-scales to zero is coming any time soon, will the following strategy work?

  1. Have instances of Cloud SQL, a Baby and a Papa. They follow the master/slave replica principle, with twist. The Baby instance is small with few vCPU's and low memory, it always runs, but does so cheaply. However, the Papa instance is expensive with high vCPU and high memory but runs only when needed.
  2. To begin, only the Baby Cloud SQL instance is running so it is the master that accepts reads/writes. The Papa Cloud SQL instance is not running.
  3. Since I am using standard app engine that will auto-scale to zero with no traffic, schedule a cron job that checks every 10 min if no app engine instances exists. In this case, the application has no traffic. If this is not the case, the Papa Cloud SQL instance is started. Once started, the Papa instance becomes the master that accepts reads/writes while the Baby instance becomes a slave replica capable of only reads.
  4. If the cron job detects the app engine has zero instances running, this means there is no traffic. Thus, the Papa Cloud SQL instance is stopped and the Baby Cloud SQL replica is promoted to master and can accept reads/writes.
  5. In this way, the expensive Papa instance runs on demand. If there is a traffic spike when the Papa instance is stopped or rebooting, the Baby instance will still be able to respond to requests.

This strategy ensures that the expensive Papa Cloud SQL instance only runs with traffic. Is this Baby-Papa dynamic possible on Google Cloud?

Rage
  • 127
  • 5

1 Answers1

1

Google Cloud does not position Cloud SQL as "serverless" or more accurately scale to zero. Their storage where you don't have to care about instances at all are Cloud Datastore or Firebase. Which is a design decision with some consequence as those are not SQL. For now let's assume staying with SQL.

Test your custom scaling scheme to see if it meets your needs. Is App Engine scale a useful trigger for DB scale? Do these scripts you write accomplish a successful cutover, automatic and without data loss? What cost savings exist with two copies of the data in two instances?

Consider an alternative of only one SQL instance, with high availability disabled. Edit the instances CPUs and memory to get a different size. Simpler, no replicas. Costs a few minutes downtime.

The only way to reduce costs for Cloud SQL that is addressed in the official documentation is decreasing the CPU, Memory, Networking or Storage. You can also study commitments as a way of reducing some of the costs.

Roger
  • 27
  • 6
John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • App engine is a useful trigger for DB scale. If 1 or more app engine instances are running, this means that users are using my service and thus will be hitting my database. This means the fast but expensive instance should be running. However, when traffic stops altogether, app engine will have 0 instances, and I can safely stop my expensive instance as no database hits are being made. Yes, there is no data loss. Having two copies is only as expensive as how many CPU's and memory they have, intra-regional network egress has zero cost. Your alternative is what I have now, far too expensive. – Rage Apr 24 '21 at 22:20