Re: миграция н

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.

--
С уважением, Виктор

In response to

Browse pgsql-ru-general by date

  From Date Subject
Next Message Genix 2005-04-04 11:50:14 максимальное количество используемой памяти
Previous Message Genix 2005-04-04 11:34:17 Re: миграция н