Re: миграция н
От | Viktor Vislobokov |
---|---|
Тема | Re: миграция н |
Дата | |
Msg-id | 42512802.5040502@lukoilperm.ru обсуждение исходный текст |
Ответ на | Re: миграция н (Genix <genix@list.ru>) |
Список | 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. -- С уважением, Виктор
В списке pgsql-ru-general по дате отправления: