Cloud SQL isn't a compatible reimplementation, it's the same vanilla MySQL that you know and love, but with a few tweaks (such as removal of SUPER privileges so you can't bork your backups, which is rather important as a managed service).
Second Generation instances should have better uptime than First Generation, as we now have live migration ala GCE if the host machine requires maintenance, and we can upgrade much of the infrastructure without restarting MySQL as we used to.
We do have failover capabilities for Second Generation instances if a zone goes down, so we're hoping between failover between zones and host migration we should have some really good uptime.
Any idea on how long a failover takes? Seems to be about 30 seconds for First generation cloud SQL, is it the same-ish for 2nd generation?
Only thing I don't love about the Cloud SQL is the failover time, but I guess if it stays at 30 seconds and doesn't fail too much - it is still way better than trying to run my own SQL server.
a) First responders actually being engineers who know the code well, can reference the open source repositories pointing to where issues are and suggesting workarounds.
b) Full workarounds being coded by the first responder (in Python for our use but they officially support other languages too) which are simple drop in replacement to fix the problem temporarily until the root cause is addressed.
c) Fast troubleshooting of critical issues (within minutes) with helpful debugging advice to resolve the issue.
d) A single contact owning the issue by default, with handover to alternative timezones on requst e.g. when an issue is long running or (in my case) you were in one location for a few weeks then change to another.
e) Consistently achieving the above over 1+ years worth of tickets, including responses handled from Google support teams worldwide to fit into the timezone e.g. Tokyo based support answering questions UK time Sunday night (Monday in Tokyo).
f) The same level of support offered for alpha and beta products even though the official word is "best effort/no SLA"
Where it has been more frustrating is with bugs discovered in the products. These have tended to be escalated to the engineering teams which take a while to fix the root cause, although acceptable workarounds are provided in the meantime. Their support ticket UI is also pretty rubbish.
Google might have a poor reputation for support when you're a consumer, but then you're not paying them anything. For both Google Cloud and Google Apps, their support has been excellent.
We hear you. We know this is a problem. Unfortunately, there are non-trivial infrastructure changes that need to happen before we can make progress, but it's high on our list of priorities. Once we can make it happen, we will.
Right now, the proxy linked below is a good solution, particularity for Managed VMs.
,,The Cloud SQL Proxy provides secure access to your Cloud SQL Second Generation instances. ... It is especially useful when connecting from clients with dynamic IP address, such as Managed VM and Google Container Engine applications."
Lack of private IPs has been the single reason why we've not moved our current dbs over. I'm sure it's hard but you're Google after all o_0
Looking at Amazon's m4 instances vs Google's standard instances.
n1-standard-2=$0.1930 db.m4.large=$0.175
n1-standard-4=$0.3860 db.m4.xlarge=$0.35
n1-standard-8=$0.7720 db.m4.2xlarge=$0.70
n1-standard-16=$1.5445 db.m4.4xlarge=$1.401
Also curious about the on demand option. I had it in 1st gen but its gone now. I can only select Always on or Never. I had a large database that I only used for a few hours per month. I'd love to migrate to second gen but if its always in it might make it much more expensive.
At last I tried to perform an export from 1st gen into 2nd gen and I'm getting server errors will try again later.
Please email cloud-sql@google.com with your instance names and the error message, and I'll get someone to look into it for you.
Second Gen is indeed always on. Crunch the numbers for your use case, I've been told by the pricing mavens that for many use cases Second Gen ends up cheaper. And yeah, Second Gen doesn't follow your AppEngine app the way it used to. This will be a call you need to make based on your use case. If you are low-traffic and highly latency-bound and your app runs on App Engine, first gen may (may) be quicker. For other bounds (I/O, RAM, CPU) you should expect better performance from Second Gen.