Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС.

2010/11/19 Sergej Kandyla <sk(at)hlsrv(dot)com>

> Возникает вопрос: как очищать архивную директорию от уже не
>> нужных
>> (более ранних) файлов транзакций, которые были до
>> очередного полного
>> бакапа (tar), чтобы каталог не распух.
>>
>>
>> Я делаю так:
>> бекап (tar) раз в неделю в $backup_dir/current/data/, wal
>> пишется в $backup_dir/currept/xlog/
>> Перед бекапом current переименовывается в previous, а
>> струкрура директорий в current пересоздается.
>>
>>
>> а чем pg_dump не подходит?
>>
>>
>> Попробуйте сделать дамп базы в несколько хотя бы десятков Гб и вы поймете
>> чем. Ну и возможность вернуться к любому состоянию минимум за неделю назад
>> иногда очень помогает.
>>
>> ну так я и спрашиваю, чтобы лучше понять )
>

ок, вот более подробно о причинах:
1) dump в любой формат (самое быстрое на моих данных - compressed формат без
компресии pg_dump <...> -F c -Z 0) занимает намного больше времени чем tar
(без компресии и даже с небольшим уровнем компресии).
2) восстановление как правило занимает еще большее время (потому что
пересоздаются индексы/перепроверяются констрейны/...). Паралельное
выполнение в 8.4 отчасти помогает, но но всегда есть возможность перейти на
8.4+
3) если в базе много бинарных данных, дамп занимает больше места чем снапшот
4) приходится делать дамп каждый день. Снапшот же можно делать раз в
неделю/месяц (в зависимости от количества записей в бд) и хранить бинарные
логи начиная с момента начала снапшота.

> Несколько десятков Гб, как бы и упаковываться архиватором будут не быстро.
> Делать с живой базы нельзя - бекап будет не консистентным.

Данные в любом случае консистенты. В случае pg_dump - за счет MVCC, в случае
снапшота - благодаря процедурам pg_start_backup и pg_stop_backup и
сохранению wal файлов.

PS: сорри за офтоп в этой ветке

--
Vladimir Rusinov
http://greenmice.info/