Re: Беда с бекапами postgresql.

Lists: pgsql-ru-general
From: "Vladimir Rusinov" <vladimir(at)greenmice(dot)info>
To: pgsql-ru-general(at)postgresql(dot)org
Subject: Беда с бекапами postgresql.
Date: 2008-09-16 08:23:38
Message-ID: f6fdfb550809160123y14ee73dcseeab2cf235cfe6cb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-ru-general

Уважаемое сообщество, нужна ваша помощь.

Некоторое время назад, примерно через неделю после перехода с 8.1 на 8.3
postgresql стал совершенно неадекватно вести себя во время бекапов: почти
каждый раз он входит в recovery mode и отвечает на все попытки соединения
что мол 'database is in recovery mode'.

Бекапы делаются следующим образом:

Я написал скриптик на python, который делает SELECT * FROM pg_tables WHERE
...; и потом запускает pg_dump <bla-bla-bla> -t <tablename>.
Кроме того, он также себя ведет и во время снятия снапшота для pitr. (SELECT
pg_start_backup(); затем копирование $PGDATA; затем SELECT
pg_stop_backup()).

В момент бекапа виден один процесс postmaster, и один процесс postgtresql с
COPY, в логах - нормальная активность до начала бекапа и сообщения о том что
connection refused потому что database is in recovery mode примерно через
минуту после начала бекапа.
Что происходит во время снятия снапшота не получилось посмотреть.

PGDATA расположена на hardware RAID1, за которым следят местные сисадмины.
Бекапы сразу идут на внешний usb-диск, и получаются судя по всему целыми
(однако на 100% не уверен). Памяти хватает, нагрузка cpu и диска - ничем не
выделяется от нормальной ситуации снятия бекапов.\

Что это может быть? Есть какие-нибудь идеи?

--
Vladimir Rusinov
http://greenmice.info/


From: Maxim Boguk <mboguk(at)masterhost(dot)ru>
To: Vladimir Rusinov <vladimir(at)greenmice(dot)info>
Cc: pgsql-ru-general(at)postgresql(dot)org
Subject: Re: Беда с бекапами postgresql.
Date: 2008-09-16 08:53:57
Message-ID: 48CF7425.6010905@masterhost.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-ru-general

Надо всетаки внимательно смотреть логи базы на предмет ошибок.

Варианта я предполагаю два:
1)процесс базы умирает по memory limit (как правило процесс базы к
которому цепляется pg_dump достаточно распухает) Надо смотреть limits -a
и прикидывать.
2)процесс базы умирает на дисковой ошибке.

В обоих случая должна быть запись в лог базы так что надо внимательно
его еще раз почитать. И посмотреть нету ли чего в /var/log/messages
странного в это время.

Сообщение "database is in recovery mode" возникает в случае полного
падения postgres когда он перазапускается аварийно.

PS: а зачем такая странная схема backup используется? потабличный backup
как вы его делаете может потом не залится если используются forein
keys и база активно обновляется.

> Уважаемое сообщество, нужна ваша помощь.
>
> Некоторое время назад, примерно через неделю после перехода с 8.1 на 8.3
> postgresql стал совершенно неадекватно вести себя во время бекапов:
> почти каждый раз он входит в recovery mode и отвечает на все попытки
> соединения что мол 'database is in recovery mode'.
>
> Бекапы делаются следующим образом:
>
> Я написал скриптик на python, который делает SELECT * FROM pg_tables
> WHERE ...; и потом запускает pg_dump <bla-bla-bla> -t <tablename>.
> Кроме того, он также себя ведет и во время снятия снапшота для pitr.
> (SELECT pg_start_backup(); затем копирование $PGDATA; затем SELECT
> pg_stop_backup()).
>
> В момент бекапа виден один процесс postmaster, и один процесс
> postgtresql с COPY, в логах - нормальная активность до начала бекапа и
> сообщения о том что connection refused потому что database is in
> recovery mode примерно через минуту после начала бекапа.
> Что происходит во время снятия снапшота не получилось посмотреть.
>
> PGDATA расположена на hardware RAID1, за которым следят местные
> сисадмины. Бекапы сразу идут на внешний usb-диск, и получаются судя по
> всему целыми (однако на 100% не уверен). Памяти хватает, нагрузка cpu и
> диска - ничем не выделяется от нормальной ситуации снятия бекапов.\
>
> Что это может быть? Есть какие-нибудь идеи?
>
> --
> Vladimir Rusinov
> http://greenmice.info/