Re: Re: [pgsql-ru-general] Оптимизация на уровне ОС.
От | Sergej Kandyla |
---|---|
Тема | Re: Re: [pgsql-ru-general] Оптимизация на уровне ОС. |
Дата | |
Msg-id | 4CE6921C.9000902@hlsrv.com обсуждение исходный текст |
Ответ на | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС. (Vladimir Rusinov <vladimir@greenmice.info>) |
Ответы |
Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС.
Re: [pgsql-ru-general] Re: [pgsql-ru-general] Оптимизация на уровне ОС. |
Список | pgsql-ru-general |
Vladimir Rusinov wrote: > > > 2010/11/19 Sergej Kandyla <sk@hlsrv.com <mailto:sk@hlsrv.com>> > > Vladimir Rusinov wrote: > > > 2010/11/16 Mihail Nasedkin <m.nasedkin@gmail.com > <mailto:m.nasedkin@gmail.com> <mailto:m.nasedkin@gmail.com > <mailto:m.nasedkin@gmail.com>>> > > > Возникает вопрос: как очищать архивную директорию от уже не > нужных > (более ранних) файлов транзакций, которые были до > очередного полного > бакапа (tar), чтобы каталог не распух. > > > Я делаю так: > бекап (tar) раз в неделю в $backup_dir/current/data/, wal > пишется в $backup_dir/currept/xlog/ > Перед бекапом current переименовывается в previous, а > струкрура директорий в current пересоздается. > > > а чем pg_dump не подходит? > > > Попробуйте сделать дамп базы в несколько хотя бы десятков Гб и вы > поймете чем. Ну и возможность вернуться к любому состоянию минимум за > неделю назад иногда очень помогает. > ну так я и спрашиваю, чтобы лучше понять ) Несколько десятков Гб, как бы и упаковываться архиватором будут не быстро. Делать с живой базы нельзя - бекап будет не консистентным. Или имеется ввиду уже архивировать данные со снапшота?
В списке pgsql-ru-general по дате отправления: