Re: Seeking datacenter PITR backup procedures [RESENDING]
От | Decibel! |
---|---|
Тема | Re: Seeking datacenter PITR backup procedures [RESENDING] |
Дата | |
Msg-id | 647C68AD-0179-44DC-88EC-4954A9599F9D@decibel.org обсуждение исходный текст |
Ответ на | Re: Seeking datacenter PITR backup procedures [RESENDING] (Bill Moran <wmoran@potentialtech.com>) |
Ответы |
Re: Seeking datacenter PITR backup procedures [RESENDING]
|
Список | pgsql-general |
On Aug 19, 2007, at 7:23 AM, Bill Moran wrote: >> Assumptions: >> a. After pg_stop_backup(), Pg immediately recycles log files and >> hence wal >> logs can be copied to backup. This is a clean start. > > I don't believe so. ARAIK, all pg_stop_backup() does is remove the > marker that pg_start_backup() put in place to tell the recovery > process > when the filesystem backup started. I'm pretty certain that's not the case. For a PITR to ensure that data is back to a consistent state after a recovery, it has to replay all the transactions that took place between pg_start_backup and pg_stop_backup; so it needs to know when pg_stop_backup() was actually run. > By not backing up pg_xlog, you are > going to be behind by however many transactions are in the most recent > transaction log that has not yet been archived. Depending on how > often > your databases are updated, this is likely acceptable. If you need > anything more timely than that, you'll probably want to implement > Slony or some other replication system. Just keep in mind that Slony is *not* a backup solution (though you could possibly argue that it's log shipping is). -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-general по дате отправления: