From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Magnus Persson *EXTERN*" <magnus(dot)e(dot)persson(at)gmail(dot)com>, PgSQL Novice <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Backup options? |
Date: | 2014-09-16 06:41:36 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B17D36F3A@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Magnus Persson wrote:
> What implications does a call to pg_dumpall have on my databases?
It will cause load (mostly I/O).
It will start long-running transaction that can cause autovacuum to lag behind
on cleaning up busy tables, leading to database bloat.
> Is there even a remote chance that a lock could be started by pg_dumpall?
The only locks are on tables, and they only block ALTER/DROP TABLE.
> If we consider that I for some reason or the other can't use pg_dumpall against the production
> clusters, what are my options? One idea is that of using asynchronous replication and pull the dumps
> off of them. Are there any pitfalls related to the replication?
Yes; unless configured properly, the dump may fail because of conflicts.
You'd have to use hot_standby_feedback=on, and that again can cause bloat
on the master cluster as described above.
> During normal operations, will
> postgres ensure that the state on the slaves always reflect the state of the masters? In effect it
> would work similar to if I did the dump on the production servers? I recall reading something about
> asynchronous replication, but I'm unsure of what it was exactly or if it affects backups.
The standby database is identical to the master database, but it may be
a little behind. That is no problem at all for a backup.
Don't use synchronous replication for this purpose.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Sameer Kumar | 2014-09-19 01:11:04 | Re: WAL for backup |
Previous Message | John DeSoi | 2014-09-15 20:45:54 | Re: Backup options? |