91–100 of 108 posts
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
We did, but now use https://aiven.io Highly recommended if you want a fast and featured managed db service.
Started down the path of using this when it was in beta, but had to abort when we saw there was no option to connect to it from Python App Engine Standard. Now that it's GA...it looks like that hasn't changed. Is the classic, Python, App Engine standard becoming a second class citizen? Or was there some reason why this wasn't considered GA worthy for Postgres? Trying to understand if going forward Google is trying to…
[I am a Googler and my team works on part of this] You can connect to postgres from app engine standard... as long as its Java. See this doc https://cloud.google.com/appengine/docs/standard/java/cloud-... And no, appengine standard is not a second class citizen. Hand-wave-ily, the connectivity path that flex uses works for postgres with minimal changes, but unfortunately some additional work is required to get appeng…
Earlier quoted context omitted.
"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…
> they have some ridiculous technology that maintains network connections and re-routes them when everything switches to the new VM 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.
(disclaimer: I'm one of the many authors on the paper, although for building parts of the underlying tech, not writing the prose)
Started down the path of using this when it was in beta, but had to abort when we saw there was no option to connect to it from Python App Engine Standard. Now that it's GA...it looks like that hasn't changed. Is the classic, Python, App Engine standard becoming a second class citizen? Or was there some reason why this wasn't considered GA worthy for Postgres? Trying to understand if going forward Google is trying to…
Earlier quoted context omitted.
[I'm the Cloud SQL TL] No, it isn't. We agree with you that it's an important feature for managed databases, and we're working to get it right. We decoupled it from this launch to get PostgreSQL to GA faster.
Unrelated to pg but could you badger the spanner team to make a mini spanner product :) Related to postgres. We have many many concurrent connections but a load satisfied by an n1-standard-4 atm do you recommend a connection pooler or something to help us get down to the 100 to 200 connections we need to be at to use cloudsql?
Earlier quoted context omitted.
Last I checked it wasn't possible to whitelist internal IPs (e.g. Kubernetes nodes or VM instances) to access Cloud SQL instances at all -- the options are either to use the non-standard cloud SQL proxy sidecar app, or allow connections from all endpoints (public or private). This seems like a major omission, and AWS has had this for ages.
From the docs: https://cloud.google.com/sql/docs/postgres/connect-external-... > You can grant any application access to a Cloud SQL instance by authorizing the IP addresses that the application uses to connect. > You can not specify a private network (for example, 10.x.x.x) as an authorized network. > PostgreSQL instances support only IPv4 addresses. They are automatically configured with a static IP address.
I believe the same issue would apply to VM instances that are not pets, (in auto-scaling groups for example), since I'm not aware of being able to auto-assign static IPs there either.
Earlier quoted context omitted.
[I'm the Cloud SQL TL] I can't comment on timelines, but we're aware that customers are interested in more features around maintenance window scheduling, deferral, and notification, as well as shorter downtime for updates and smarter scheduling within a group of replicas.
Can you confirm that it's impossible to avoid downtime, even with HA, because of forced updates? Surely that's what HA is? no downtime as you update each node one at a time? If it's impossible then it's a dealbreaker.
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...
Block device based replication for Postgres seems a bit unconventional given that Postgres has native synchronous replication support with WAL streaming. Intuition tells me that you might get better performance if you let the DB itself do the replication but I can't really justify that without real review of what happens. The postgres docs ( https://www.postgresql.org/docs/10/static/different-replicat... ) say that t…
Amazon claims better scaling then ordinary Postgres for this.
Earlier quoted context omitted.
They're the best we've found as well, but there are lots of managed database providers of all kinds. https://www.compose.com is another big one.
We’re using compose for redis, but we might switch it to aiven as well, despite aiven having some missing functionality... For Gcloud and especially in Europe, I think these two are the only options that I’m aware of (at least for PG and redis)
I tried using this, but couldn't get the root certs to work. So I went to AWS RDS instead. A pity, it's much cheaper ( especially in beta pricing )
When you say you couldn't get the root certs to work... what do you mean?
Cloud SQL automatically generates server certificates, and we offer UI+API for creating additional client certificates. The two should not share a root CA.