Re: Forcing current WAL file to be archived
От | Stephen Frost |
---|---|
Тема | Re: Forcing current WAL file to be archived |
Дата | |
Msg-id | 20060725164726.GN20016@kenobi.snowman.net обсуждение исходный текст |
Ответ на | Re: Forcing current WAL file to be archived (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
* Bruce Momjian (bruce@momjian.us) wrote: > Tom Lane wrote: > > You are assuming here that the continuous archiving process is identical > > to the WAL part of the base-backup process. If what you want is an > > identifiable self-contained base backup then you copy off the WAL files > > along with the tar dump; there's no need to force a switch of the > > current WAL file before you copy it. > > If you are doing that, I think for consistency you would want a WAL file > that is completely archived, rather than pulling the current one while > it is being written to. I've never been terribly pleased with having to copy the current WAL while it's being written to. The setup we're using is basically: On the source system: pg_start_backup() rsync pg_stop_backup() Figure out the current WAL and do a fake archive of it On the backup server: Grab the start/end WAL logs of the backup Verify that all the WAL logs archived during the backup are available It sounds like I'd be changing "do a fake-archive of the current WAL" to "call the archive_wal function". In either case I worry some about a possible race-condition or something going wrong which invalidates the backup. I think it would actually be really nice to have a 'verify_backup' tool which could be non-interactively run against a backup to check that the backup was successful. The one we hacked up really just checks that there are files available with the right names. Something more substantial than that (but without affecting the actual backup) would be really nice since it would improve confidence that the backup really can be restored from. Thanks, Stephen
В списке pgsql-hackers по дате отправления: