Cloud SQL for PostgreSQL adds high availability and replication | Hacker News Reader

Cloud SQL for PostgreSQL adds high availability and replication

cloudplatform.googleblog.com

146 pointsdantiberian19 comments

This blog post is confusing, and I'm having trouble figuring out what they're talking about in the Cloud SQL documentation. What are these regional disks? Why should I care about them as a customer?

Their mention of replication makes it sound like they are behaving similarly to RDS' Aurora instances ie. they store data using something like Google Cloud Storage, and replicas all read from the same storage location instead of doing "real" logical replication, and data modifications are handled using copy-on-write.

If anyone can explain, I'd really appreciate it.

My understanding is that there are two VMs running in different zones within the same region, the primary, and a failover. Instead of writing to a zonal disk (the standard behaviour for a non-HA Cloud SQL instance), the primary's writes go to a new Regional Disk. The regional disk is replicated synchronously between two zones, rather than writes going to a single zone.

The obvious question you're having here is "Won't that be slower?" and the answer is yes it will necessarily be slower due to physics. However on the Google Cloud public Slack (https://gcp-slack.appspot.com), it was mentioned that networking for zone to zone is similar to machine to machine, so this is likely to not be an issue.

If the primary instance fails (either because of machine/rack/zone failure), it will stop sending heartbeats and the failover will try to mount the regional disk and become the primary. Because all writes are synchronously replicated, no data loss occurs, although your service will be unavailable until failover completes.

> Their mention of replication makes it sound like they are behaving similarly to RDS' Aurora instances

I don't think anything this fancy is happening, to my understanding it is just a disk that happens to be synchronously replicated to two zones. Under the covers they may be doing some smart copy-on-write stuff, but that isn't exposed to the user.

From the sound of the blog post they plan to unveil regional disks sometime soon, so we may get more info then.

> From the sound of the blog post they plan to unveil regional disks sometime soon, so we may get more info then.

Someone from Google confirmed this in a comment: "Regional Disks will first be used by managed services like Cloud SQL, but watch for a future announcement about Regional Disks as a public feature".

Read replicas probably use ordinary Postgres replication (WAL shipping is a proven technology). This is evidenced by the fact that replicas cannot be promoted to master and therefore cannot be used for HA; HA masters require the new "regional disk" system to work.

Is anybody here who has used both AWS RDS and Google Cloud SQL? Any feedback/comparison? Any special points one should consider while moving from RDS to Cloud SQL?

I use both. From an application perspective, i haven't noticed a difference. The Google console is much easier to use however. The one big difference i know of is that on google cloud sql, they dont give you super admin.

Thanks for the info. Planning to try out Cloud SQL soon.

Been looking forward to this as well. RDS is a solid service but it’s good to have competition. Will be great to see PostgreSQL adoption widening and growing with 2 major cloud provider offering it as managed service.

MS Azure also provides Postgres now [1]. And also does Alibaba Cloud [2]. They even have a special version of it – something for analytics/warehousing [3]. So at least 4 big cloud providers have Postgres!

1) https://azure.microsoft.com/en-us/services/postgresql/

2) http://www.pgconf.asia/JP/wp-content/uploads/2016/12/Postgre...

3) https://www.alibabacloud.com/product/hybriddb-postgresql

NodeChef, though not a major cloud provider provides hosted PostgreSQL. https://nodechef.com/docs/postgresql

Awesome news! My job involves using the current mysql cloud SQL with replication, and boy does it suck. Every schema change (even adding an index) causes the replica to get stuck behind and never catch up. Apparently this is a 'documented limitation' and deleting/recreating the replica is the supposed solution.

Urgh. I'm hoping this is a mysql issue and pg doesn't suffer from this.

I would assume this has to do with MySQL's lack of transactional DDL, but I haven't looked into it at all. I actually don't mind MySQL as much as people complain about it, but I haven't dealt with any cases that requires more than a single read replica.

Replica as in Read Replica? Are you using V2? We are using read replicas and are not facing any such problems

Good news, it's a pitty that it's still in beta. I would love to use it for a project that should run in production and so on i'm "stuck" with VM running postgress and replication with repmgr and barman. it works, but it's a lot of work to set it up and mange it.

Awesome! Was creating an instance today and saw the welcome addition. Had to do a double take.

Since there are some GCP folks here occasionally: is there any ETA for PostgreSQL going GA in Google Cloud?

Would love to use it, but can't use it in beta.

I am currently starting a project using heroku (node.js/postgres). Is there any reason to try out app engine with cloud sql instead?

If you know Heroku and you’re not worried about its price then stick with it. Move to GCP when Heroku becomes too expensive.

Go price a database with say 100gb of data.

Reply on news.ycombinator.com