Hacker News Reader

Comment by Lewisham | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com