From: | "Viktor Vislobokov" <vvislobokov(at)parma-telecom(dot)ru> |
---|---|
To: | pgsql-ru-general <pgsql-ru-general(at)postgresql(dot)org> |
Subject: | Re: миграция н |
Date: | 2005-04-04 11:41:54 |
Message-ID: | 42512802.5040502@lukoilperm.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
На что-то отвечу, на что-то нет:
>
>> - Вместо UPDATE STATISTICS в Informix, здесь есть свои команды VACUUM.
>
>
> сейчас у меня update statistics делается раз в день (ночью). Как
> частно необходимо делать vacuum для pg?
Точно такие же сообращения как и для UPDATE STATISTICS.
> что скажет общественность про восстановление данных рухнувших баз? что
> есть для этого в pg? как выглядит сам процесс восстановления
> (интересует практический опыт, а не бумажная теория).
Если база рухнула и нету бакапа, то хрен его знает как это чинить. Тут
только теоретические есть соображения.
>
> умеет ли pg вести онлайновый лог операций? т.е. писать все в
> какой-либо журнал по мере совершения действий на сервере. ну или хотя
> бы (что даже еще лучше) писать в журнал разницу между последними
> изменениями относительно какой-либо стадии логирования?
Есть WAL - write-ahead logs. Помоему - это то о чём ты и говоришь
> насколько эффективны встроенные средства бекапа?
>
Бакап делается через pg_dump (для базы) или pg_dumpall (для всех баз).
Бакап получается в виде текстового файла с операторами SQL,
так что всё очень переносимо и надёжно и даже возможна правка.
Разумеется, что никто не мешает перенаправить стандартный вывод из
pg_dump в gzip или даже bzip2 и получить сжатый бакап базы.
Восстановление - это накат дампа + WAL.
--
С уважением, Виктор
From | Date | Subject | |
---|---|---|---|
Next Message | Genix | 2005-04-04 11:50:14 | максимальное количество используемой памяти |
Previous Message | Genix | 2005-04-04 11:34:17 | Re: миграция н |