Re: Archive log compression keeping physical log available in the crash recovery

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Archive log compression keeping physical log available in the crash recovery
Дата
Msg-id 8A8A4F68-FDC5-401B-97E9-D67AECA9387E@decibel.org
обсуждение исходный текст
Ответ на Archive log compression keeping physical log available in the crash recovery  (Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>)
Ответы Re: Archive log compression keeping physical log available in the crash recovery  (Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>)
Список pgsql-hackers
I thought the drive behind full_page_writes = off was to reduce the  
amount of data being written to pg_xlog, not to shrink the size of a  
PITR log archive.

ISTM that if you want to shrink a PITR log archive you'd be able to  
get good results by (b|g)zip'ing the WAL files in the archive. I  
quick test on my laptop shows over a 4x reduction in size. Presumably  
that'd be even larger if you increased the size of WAL segments.

On Jan 29, 2007, at 2:15 AM, Koichi Suzuki wrote:

> This is a proposal for archive log compression keeping physical log  
> in WAL.
>
> In PotgreSQL 8.2, full-page_writes option came back to cut out  
> physical
> log both from WAL and archive log.   To deal with the partial write
> during the online backup, physical log is written only during the  
> online
> backup.
>
> Although this dramatically reduces the log size, it can risk the crash
> recovery.   If any page is inconsisitent because of the fault, crash
> recovery doesn't work because full page images are necessary to  
> recover
> the page in such case.  For critical use, especially in commercial  
> use,
>  we don't like to risk the crash recovery chance, while reducing the
> archive log size will be crucial too for larger databases.    WAL size
> itself may be less critical, because they're reused cyclickly.
>
> Here, I have a simple idea to reduce archive log size while keeping
> physical log in xlog:
>
> 1. Create new GUC: full_page_compress,
>
> 2. Turn on both the full_page_writes and full_page_compress: physical
> log will be written to WAL at the first write to a page after the
> checkpoint, just as conventional full_page_writes ON.
>
> 3. Unless physical log is written during the online backup, this  
> can be
> removed from the archive log.   One bit in XLR_BKP_BLOCK_MASK
> (XLR_BKP_REMOVABLE) is available to indicate this (out of four, only
> three of them are in use) and this mark can be set in XLogInsert().
> With the both full_page_writes and full_page_compress on, both logical
> log and physical log will also be written to WAL with  
> XLR_BKP_REMOVABLE
> flag on.  Having both physical and logical log in a same WAL is not
> harmful in the crash recovery.  In the crash recovery, physical log is
> used if it's available.  Logical log is used in the archive  
> recovery, as
> the corresponding physical log will be removed.
>
> 4. The archive command (separate binary), removes physical logs if
> XLR_BKP_REMOVABLE flag is on.   Physical logs will be replaced by a
> minumum information of very small size, which is used to restore the
> physical log to keep other log records's LSN consistent.
>
> 5. The restore command (separate binary) restores removed physical log
> using the dummy record and restores LSN of other log records.
>
> 6. We need to rewrite redo functions so that they ignore the dummy
> record inserted in 5.  The amount of code modification will be very  
> small.
>
> As a result, size of the archive log becomes as small as the case with
> full_page_writes off, while the physical log is still available in the
> crash recovery, maintaining the crash recovery chance.
>
> Comments, questions and any input is welcome.
>
> -----
> Koichi Suzuki, NTT Open Source Center
>
> -- 
> Koichi Suzuki
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Talks for OSCON? Only 5 days left!
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: Commit timestamp