From: | Vladimir Rusinov <vladimir(at)greenmice(dot)info> |
---|---|
To: | Sergej Kandyla <sk(at)hlsrv(dot)com> |
Cc: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС. |
Date: | 2010-11-19 20:26:45 |
Message-ID: | AANLkTinb8FWp47Msz76ZzGU8TmEoyHWvEmbx-Fvzn6p4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Mihail Nasedkin | 2010-11-19 20:37:08 | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС. |
Previous Message | Mihail Nasedkin | 2010-11-19 19:32:37 | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС. |