| From: | John DeSoi <desoi(at)pgedit(dot)com> |
|---|---|
| To: | Magnus Persson <magnus(dot)e(dot)persson(at)gmail(dot)com> |
| Cc: | PgSQL Novice <pgsql-novice(at)postgresql(dot)org> |
| Subject: | Re: Backup options? |
| Date: | 2014-09-15 20:45:54 |
| Message-ID: | 62DDFFBB-88F1-4EB1-96C5-501E15767257@pgedit.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
On Sep 15, 2014, at 2:06 PM, Magnus Persson <magnus(dot)e(dot)persson(at)gmail(dot)com> wrote:
> 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? 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.
Yes, this approach works, but it is not without possible problems. You may have to repeat a failed backup because of query conflicts. See
http://www.postgresql.org/docs/current/static/hot-standby.html#HOT-STANDBY-CONFLICT
John DeSoi, Ph.D.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2014-09-16 06:41:36 | Re: Backup options? |
| Previous Message | Magnus Persson | 2014-09-15 19:06:59 | Backup options? |