4 ms·
Basically, Cloud SQL databases are written out to Google's storage system, which automagically replicates across several datacenters. If the primary datacenter
by Lewisham 13y ago
Basically, Cloud SQL databases are written out to Google's storage system, which automagically replicates across several datacenters. If the primary datacenter that your database is in goes down, it's still replicated across other datacenters and the data at rest isn't at risk. When a connection comes in, we see that the database isn't up right now, and spin in up into a new datacenter (this happens automatically if your database is always on).
We offer two different ways of working with Cloud SQL: synchronous and asynchronous writes. With the synchronous writes, you'll get an OK back when you update the database, which lets you know that the write completed successfully and is replicated. If something bad happens, you'll get an exception back and can keep the data in memory until the database is live and accepting connections again.
A faster method is asynchronous, which performs the writes every second or so, so you're not waiting for replication to complete. If something dies during that second, you could lose data during that period and not know it.
Does this help?
Disclaimer: I'm a developer on Cloud SQL.
- curiousDog 13y agoAh I see, so the database sits in a shared storage network and you spin-up a VM with MySQL when needed? If yes, is latency a concern? Also, if my database goes cold, will you spin down the VM?
- Lewisham 13y agoExternally it appears this way (I can't talk about infrastructure in any real detail). Latency is the same as if you were running MySQL on any other platform AFAIK. If the database is cold, yes, the DB is spun down. An incoming connection will cause the DB to spin up, and in most languages the common MySQL connector will block until it's ready, so it doesn't require special coding around. Databases almost always come up in a matter of seconds.