Chronic performance issue with Replication Failover and FSM. - Mailing list pgsql-hackers

From Josh Berkus
Subject Chronic performance issue with Replication Failover and FSM.
Date
Msg-id 4F5FDE11.3030407@agliodbs.com
Whole thread Raw
Responses Re: Chronic performance issue with Replication Failover and FSM.  (Daniel Farina <daniel@heroku.com>)
Re: Chronic performance issue with Replication Failover and FSM.  (Fujii Masao <masao.fujii@gmail.com>)
Re: Chronic performance issue with Replication Failover and FSM.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Chronic performance issue with Replication Failover and FSM.  (Daniel Farina <daniel@heroku.com>)
List pgsql-hackers
All,

I've discovered a built-in performance issue with replication failover
at one site, which I couldn't find searching the archives.  I don't
really see what we can do to fix it, so I'm posting it here in case
others might have clever ideas.

1. The Free Space Map is not replicated between servers.

2. Thus, when we fail over to a replica, it starts with a blank FSM.

3. I believe replica also starts with zero counters for autovacuum.

4. On a high-UPDATE workload, this means that the replica assumes tables
have no free space until it starts to build a new FSM or autovacuum
kicks in on some of the tables, much later on.

5. If your hosting is such that you fail over a lot (such as on AWS),
then this causes cumulative table bloat which can only be cured by a
VACUUM FULL.

I can't see any way around this which wouldn't also bog down
replication.  Clever ideas, anyone?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade and statistics
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade and statistics