From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Chris Travers <chris(dot)travers(at)gmail(dot)com> |
Cc: | Guyren Howe <guyren(at)gmail(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Uber migrated from Postgres to MySQL |
Date: | 2016-07-27 17:02:40 |
Message-ID: | 20160727170240.GE27332@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jul 27, 2016 at 09:17:58AM +0200, Chris Travers wrote:
> The replication section made me wonder though if they were using the right
> replication solution for the job. If you don't want an on-disk copy, don't use
> physical replication. This being said there is one serious issue here that is
> worth mentioning, which is that since autovacuum on the master has no knowledge
> of autovacuum on the slave, it is easy to have longer-running queries on a
> slave that have rows they need to see removed by autovacuum and replication.
Uh, see hot_standby_feedback:
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts
> All of the above being said, there are solutions to all the major problems.
> But you have to know about them, where to look, and what to do. And with
> higher scale, one very important aspect is that attention to detail starts to
> matter a whole lot. I agree that there are some good points raised but I
> wonder what the solutions are. There is room for some improvement in the
> backend (it would really be nice to instrument and measure toasting/detoasting
> overhead in explain analyze) but for a lot of these I wonder if that is
> secondary. PostgreSQL is very well optimized for a certain series of tasks,
> and one can build well optimized solutions well outside that. At a certain
> point (including a certain scale) therewill be no substitute for a teamof
> people who really know the db backend inside and out who can design around
> limitations and I think that is true for all databases I have worked with.
Watching the video was helpful:
You can see the failover happened because of various user errors. That
doesn't excuse our bug, but I am not sure exactly how much they
understood of Postgres behavior. His talk near the end about the
replication infrastucture being exposed to them was also interesting.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-07-27 17:04:10 | Re: Uber migrated from Postgres to MySQL |
Previous Message | Bruce Momjian | 2016-07-27 16:59:59 | Re: Uber migrated from Postgres to MySQL |