31–40 of 108 posts
Postgres wire-compatible Spanner when? :P
Wondering what kind of use case you would have for this compatibility?
Right now basically the options are Aurora, Citus, and running CockroachDB yourself.
Earlier quoted context omitted.
citus isn't simply postgresql. It has many tradeoffs
We get that, but I left off (for brevity) the reasons why Citus would be a net positive for our use case.
Will we be able to use the Citus extension? Been itching to get Citus running on GCP.
Does anyone have insight or experience using this in production? We're currently running PostgreSQL 10 w/ pg_partman on our own hardware but looking at a several options for cloud migration. Unfortunately, Citus Cloud on GCP doesn't appear to be an option (yet?) - Google Cloud SQL (PostgreSQL) - Citus Cloud (AWS Only) - Citus (managed ourselves) on GCP
citus isn't simply postgresql. It has many tradeoffs
Does anyone have insight or experience using this in production? We're currently running PostgreSQL 10 w/ pg_partman on our own hardware but looking at a several options for cloud migration. Unfortunately, Citus Cloud on GCP doesn't appear to be an option (yet?) - Google Cloud SQL (PostgreSQL) - Citus Cloud (AWS Only) - Citus (managed ourselves) on GCP
Highly recommended if you want a fast and featured managed db service.
I'm looking around for more details on these "regional" disks that replicate between two zones at the block level. Is that just a fancy term for os level mirrored disks using the cloud persistent disks?
There's a previous blog post[1] about HA replication. It uses block-level replication managed by PD infrastructure. [1] https://cloudplatform.googleblog.com/2017/11/Cloud-SQL-for-P...
Has anyone used the beta and got any feeling for how maintenance downtime impacts things? A bit nervous about how you can only set a "maintenance window" and not be able to plan ahead for disruption; as far as I can tell, they won't even tell you ahead of time. The HA seems really solid (zero-lag "regional disks"), but it's still a bit disconcerting.
Unfortunately last time I used CloudSQL for MySQL it was incredibly unstable. They would take down our master AND standby at the same time for maintenance. When we filed a ticket they just said it was a known bug with no plans to fix. A major client of mine migrated to AWS because of this and other issues.
To be fair, we wouldn't use GCP for anything but virtual servers and storage replication... I have no desire to tie us to Google's infrastructure any more than necessary.
Were your master and standby in the same availability zone? Can't you set diff maintenance windows? WTF?
https://cloud.google.com/sql/faq#maintenancerestart
According to the link above, you can taper your upgrade windows, it looks like.
Earlier quoted context omitted.
There's a previous blog post[1] about HA replication. It uses block-level replication managed by PD infrastructure. [1] https://cloudplatform.googleblog.com/2017/11/Cloud-SQL-for-P...
I read that, but it doesn't answer the question. What are these regional disks, and can they be used directly?
Regional disks aren't publicly available yet, but they are in alpha [2]. Like normal persistent disks, everything is backed by Google's internal Colossus system [3].
[1] https://cloudplatform.googleblog.com/2017/11/Cloud-SQL-for-P...
[2] https://cloud.google.com/sdk/gcloud/reference/alpha/compute/...
[3] https://cloud.google.com/files/storage_architecture_and_chal...
Earlier quoted context omitted.
Unfortunately last time I used CloudSQL for MySQL it was incredibly unstable. They would take down our master AND standby at the same time for maintenance. When we filed a ticket they just said it was a known bug with no plans to fix. A major client of mine migrated to AWS because of this and other issues.
I've been thinking about moving us to Google's Cloud Platform. What I found in regards to maintenance here: https://cloud.google.com/compute/docs/regions-zones/#mainten... states that they do live migrations without any down time. Can anyone elaborate? Is this only for Compute Engine? In that case, if one can run postgres on a Compute Engine instance, why not do that instead? Surely, if one can setup a highly availab…
You can run PostgreSQL on a VM just fine. You just have to manage itself. Cloud SQL comes with some upsides (zero management, spectacular HA failover capabilities) and some downsides (lack of extensions, lives on a separate network, no control over maintenance window); you have to decide what you're willing to live with.
You can set the upgrade window, but it can't be predicted. What you can control is the order — e.g. set your staging instance to "early" and production instance to "late", then hopefully staging should be upgraded first and you'll know ahead of the production upgrade if any issues arose.
[1] https://cloud.google.com/compute/docs/instances/live-migrati...
Earlier quoted context omitted.
I've been thinking about moving us to Google's Cloud Platform. What I found in regards to maintenance here: https://cloud.google.com/compute/docs/regions-zones/#mainten... states that they do live migrations without any down time. Can anyone elaborate? Is this only for Compute Engine? In that case, if one can run postgres on a Compute Engine instance, why not do that instead? Surely, if one can setup a highly availab…
"Live migration" refers to how Compute Engine transparently migrates a VM to another physical host [1]. Disk and memory is copied over, and they have some ridiculous technology that keeps network connections alive and re-attaches them to the new VM when it's been switched over, so that it causes, in principle, zero disruptions. This is much more magical than other providers, such as AWS and DigitalOcean, where such a…
indeed, this is the primary reason i wish to switch. i have no problem maintaining our own stuff, we do that anyway. :) thanks for the details.