Next generation of Google Cloud SQL | Hacker News Reader

Next generation of Google Cloud SQL

googlecloudplatform.blogspot.com

77 pointsaarkay33 comments

Still no Postgres :(

I've been considerably dissatisfied with AWS lately, namely their lack of real customer support for billing issues and was shopping around for a Postgres provider. http://databaselabs.io seems to be a good choice if you're looking for AWS alternative.

Compose.io also looks like a good choice https://www.compose.io/postgresql . I have no affiliation with them, just wanted to try their service for attractive pricing.

When it comes to support, Google isn't doing anything exceptional either.

I don't disagree.

I wonder if you've actually submitted a ticket to Google Cloud support at all? At the Gold level of $400/m I've had excellent experiences including:

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.

The phone support is useless though. They just open a ticket for you :/

> At the Gold level of $400/m I've had excellent experiences.

This is what's different. Yes I've submitted tickets. I did for SSL certificates related issues as they are currently migrating that functionality from google apps to developer console. I also emailed them about some issues I had with storage but nothing. Eventually I found workarounds but I guess I don't pay for support so I shouldn't be expecting it.

Not sure how well the second gen supports appengine. With 1st gen you could ask the database to follow an appengine app so they are both in the same cell. I also don't see how to allow connection from appengine apps I only can select IP addresses. Are these unnecessary now?

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.

I'd love to hear about the errors you're experiencing; if there's any bumps in the road we want to smooth them out ASAP.

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.

Looks like its neck to neck with AWS RDS MySQL. Has anyone done any benchmarks on performance?

There some benchmarks at http://www.pythian.com/blog/benchmarking-google-cloud-sql-in... but only comparing the different instance sizes, and to the first generation, which is much slower. It's good there's finally a decent managed SQL option on the Google cloud.

Oh Cool. Thanks for the link.

It is more comparable with AWS Aurora, since this is a compatible reimplementation and _not_ a MySQL box with beefed up hardware specs.

I agree with that.

Hey, I'm a software engineer on Cloud SQL.

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.

Awesome, thanks!

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.

So that depends on what's happening.

If it's host maintenance (the machine your database is on needs to be brought down) then you should "see" the same results as Google Compute Engine live migration, which is that you hopefully see nothing :) This was one of the most common reasons a first gen instance would require restarting, alongside us pushing updates. So nixing that one, alongside the other non-restarting updates we can do now, is good stuff.

If a whole zone goes down, we start the failover process automatically for you. This is order minutes. It won't be seamless, but zones going down is hopefully a very rare occurrence.

ya that makes sense, sounds pretty good.

I have a small product on a gen1 D1 with 512 mb ram. I wonder how that compares to a db-g1-small in performance. db-g1-small has more memory but not sure if it is as apples to apples as that..

Does that mean MySQL patching and updates without downtime?

No. If we need to specifically update MySQL, that's going to cause MySQL to bounce. We don't do that often (you can count on your hands the last year the number of times we actually updated MySQL), and with Second Generation you get to choose a maintenance window which we didn't have for First Gen.

What's different is that if we needed to make a change that required only querying MySQL, such as listing your databases in the UI, we would still need to bounce your instance for that functionality to come up with First Gen. With Second Gen we don't need to, so we can add many new features without restarting MySQL. I don't want to speak out of turn lest the lawyercats that come up with SLA numbers and such find me, but I am personally confident that once we exit beta, most customers should generally experience better than the 99.95% uptime we have SLA for First Gen.

Is there a better migration path for MySQL 5.5 -> MySQL 5.6 than the existing recommendation, which is ultimately "Create a new database and port your data over"?

https://cloud.google.com/sql/docs/migrating

I'm afraid not.

And still no private IPs?

It's also a shame you can't use their own firewall rules with CloudSQL, or even specify instance tags to allow traffic inbound to CloudSQL. You have to specify IP ranges (CIDR) for each of your hosts. Makes it near impossible to allow an auto-scaling group to access CloudSQL since you have no control over the public IP that will be assigned to a new host being spun up in the ASG.

It seems they approached the problem with a new solution: https://cloud.google.com/sql/docs/sql-proxy

,,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."

The proxy solution looks OK, shame it wasn't mentioned in the blog unless I'm blind.

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

Pretty much the same situation for us, too.

I was really excited about the possibility of using Cloud SQL. Unfortunately, the lack of private IP whitelisting forces you to make some tradeoffs that don't make sense from the security perspective.

Hey, I'm a software engineer on Cloud SQL.

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.

Is it just me or does Google Cloud SQL seem extremely expensive compared to the alternatives (RDS, etc)?

It's just you.

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

That's without Google's sustained use discount, so it comes out as cheaper most of the time.

Not for me! They are pretty much comparable. Google's sustained use discounts mean no lock-in, lower price and flexibility too! Considering the fact that Google Cloud's disks are way faster than AWS's disks, your overall price is much lower with Google Cloud.

Reply on news.ycombinator.com