Re: [HACKERS] RE: [GENERAL] Transaction logging
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] RE: [GENERAL] Transaction logging |
Дата | |
Msg-id | 378EE0D6.21E5B2F9@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] RE: [GENERAL] Transaction logging (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
Vadim Mikheev wrote: > > > The "restore of a server" is a main problem here, but I suggest the > > following > > additional backup tool, that could be used for a "restore of a server" > > which could then be used for a rollforward and would also be a lot faster > > than a pg_dump: > > > > 1. place a vacuum lock on db (we don't want vacuum during backup) > > 2. backup pg_log using direct file access (something like dd bs=32k) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 3. backup the rest in any order (same as pg_log) > > 4. release vacuum lock > > It looks like log archiving, not backup. > I believe that _full_ backup will do near the same > things as pg_dump now, but _incremental_ backup will > fetch info about what changed after last _full_ backup > from log. Sorry, I was wrong. pg_dump is what's known as Export utility in Oracle and backup is quite different thing. But I have corrections for full backup described above: 1. no vacuum lock is needed: all vacuum ops will be logged in normal way to rollback changes in failures; 2. all datafiles have to be backed up _before_ log backup due to WAL logic: changes must be written to log before they'llbe written to on-disk data pages. Vadim
В списке pgsql-hackers по дате отправления: