AW: AW: Backup, restore & pg_dump

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: AW: Backup, restore & pg_dump
Дата
Msg-id 11C1E6749A55D411A9670001FA6879633680B9@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Список pgsql-hackers
> > > BTW, avoiding writes is base WAL feature, ie - it'll be
> > > implemented in 7.1.
> > 
> > Wow, great, I thought first step was only to avoid sync :-)
> 
> ? If syncs are not required then why to do write call?

Yes, writes are only necessary when "too many dirty pages"
are in the buffer pool. Those writes can be done by a page flusher
on demand or during checkpoint (don't know if we need checkpoint,
but you referred to doing checkpoints).

> Currently records inserted by aborted transactions remain in db
> untill vacuum. I try to rollback changes - ie *delete* inserted
> tuples on abort (though could do not do this), - isn't there
> some difference now?

this has two sides: less space wastage, but slower rollback.
What you state is a separate issue, and is not part of the
startup rollforward for committed tx'ns. It is part of the rollback
of aborted tx'ns.

> > We should not call this tx log business "Incremental backup"
> > an incremental backup scans all pages, and backs
> > them up if they changed in respect to the last higher level backup.
> > (full backup, level 1 backup, level 2 backup ....)
> > Oracle only uses this chargon, since they don't have such a 
> > backup, and want to fool their customer's managers. 
> > All other DB companies make correct use of the wording 
> > "incremental backup" in the above sense.
> 
> Scanning *all* pages?! Not the best approach imho.
> Or did you meant scanning log to get last *committed"
> changes to all pages - ie some kind of log compression?

You could call an incremental backup some kind of log compression, yes,
but it is usually done by reading base data pages (an optimization would be to 
skip page ranges that are known to not have changed, but how do you know) 

In the backup I have in mind there are 3 things:

1. full backup
2. tx log backup
3. incremental backup with multiple levels

Point 3 is something to keep in mind, but do later.
On restore you do

restore full backup (level 0)
restore incremental backup level 1 (pages that changed after level 0)
restore incremental backup level 2 (pages that changed after level 1)
restore tx logs that were written after level 2 

The incremental backups are especially useful in an overwrite smgr,
where you can get a lot of tx log that only changes a few pages.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: time stops within transaction
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: INHERITS doesn't offer enough functionality