Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal
От | Tom Lane |
---|---|
Тема | Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal |
Дата | |
Msg-id | 22500.1294080152@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal (Scott Ribe <scott_ribe@elevated-dev.com>) |
Ответы |
Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal
|
Список | pgsql-admin |
Scott Ribe <scott_ribe@elevated-dev.com> writes: > On Jan 3, 2011, at 11:22 AM, Imre Oolberg wrote: >> But http://www.postgresql.org/docs/9.0/interactive/continuous-archiving.html suggests to use tar on rsync and i guessthat PostgreSQL recovery with wal files takes care of these inconsistencies that are created during copying filesystem,right? > Yes, but the database is recovered to the consistent state as of the pg_start_backup command, as I pointed out to you before.Results of transactions that commit after the pg_start_backup command will not be in the backed up database. That's either incorrect or poorly worded. The only way to get a consistent, usable database is to replay all the WAL that was generated between pg_start_backup and pg_stop_backup. That will fix up whatever inconsistencies exist in the base backup fileset. Once you've done that, you do have the results of transactions that committed after pg_start_backup (and up to pg_stop_backup). If you haven't done that, what you have is an inconsistent pile of rather arbitrary bits. The base backup by itself (without the concurrently-created WAL) is *useless*. regards, tom lane
В списке pgsql-admin по дате отправления: