At 00:55 1/12/00 -0800, Nathan Myers wrote:
>On Thu, Nov 30, 2000 at 11:06:31PM -0800, Vadim Mikheev wrote:
>> > As for replaying logs against a restored snapshot dump... AIUI, a
>> > dump records tuples by OID, but the WAL refers to TIDs. Therefore,
>> > the WAL won't work as a re-do log to recover your transactions
>> > because the TIDs of the restored tables are all different.
>>
>> True for current way of backing up - ie saving data in "external"
>> (sql) format. But there is another way - saving data files in their
>> natural (binary) format. WAL records may be applyed to
>> such dump, right?
>
>But (AIUI) you can only safely/usefully copy those files when the
>database is shut down.
>
This is not true; the way Vadim has implemeted WAL is to write a series of
files of fixed size. When all transactions that have records in one file
have completed, that file is (currently) deleted. When BAR is going, the
files will be archived.
The only circumstance in which this strategy will fail is if there are a
large number of intensive long-standing single transactions - which is
unlikely (not to mention bad practice).
As a result of this, BAR will just need to take a snapshot of the database
and apply the logs (basically like a very extended recovery process).
You have raised some interesting issues regrading write-order etc. Can we
assume that when fsync *returns*, all records are written - though not
necessarily in the order that the IO's were executed?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
