Re: could not write to log -> PANIC -> System down

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: could not write to log -> PANIC -> System down
Дата
Msg-id b42b73150612141300v73c21ck372e9f9d16965bf@mail.gmail.com
обсуждение исходный текст
Ответ на Re: could not write to log -> PANIC -> System down  ("Scott Marlowe" <smarlowe@g2switchworks.com>)
Ответы Re: could not write to log -> PANIC -> System down  ("Brandon Aiken" <BAiken@winemantech.com>)
Список pgsql-general
On 12/14/06, Scott Marlowe <smarlowe@g2switchworks.com> wrote:
>
>
>
> On Thu, 2006-12-14 at 11:28, dev wrote:
>  > Hello friends,
>  >
>  > we have some strange problem, postmaster (pg 8.1 /win32)
>  > suddenly shutdown because of "no reason".
>  >
>  > The interesting thing is that this occurs always at
>  > almost same time (between 0.00 and 0.30h), in that time period is
>  > running system backup (Veristas backupexec agent) - starts at 23:30.
>  > The problem occurs randomly.
>  > In two of cases we have UPDATE/INSERT operation, but in third case - no.
>  >
>  > P.S. Why "autovacuum" runs every minute almost? Is this related?
>  >
>  > Thanks in advanced!
>  >
>  >
>  > ================ LOG (2006-12-14) ==================
>  > 2006-12-14 00:00:51 LOG:  autovacuum: processing database "mtdb"
>  >
>  > 2006-12-14 00:01:52 LOG:  autovacuum: processing database "mtdb"
>  >
>  > 2006-12-14 00:02:53 LOG:  autovacuum: processing database "mtdb"
>  >
>  > 2006-12-14 00:03:54 LOG:  autovacuum: processing database "mtdb"
>  >
>  > 2006-12-14 00:04:56 LOG:  autovacuum: processing database "mtdb"
>  >
>  > 2006-12-14 00:06:02 LOG:  autovacuum: processing database "mtdb"
>  >
>  > 2006-12-14 00:06:02 ERROR:  could not write block 14725 of relation
>  > 1663/16388/61387: Permission denied
>  >
>  > 2006-12-14 00:06:02 CONTEXT:  writing block 14725 of relation
>  > 1663/16388/61387

>  Is your backup agent (vertias backupexec) doing a file system backup of
>  the $PGDATA directory?  This is probably not a good idea, especially if
>  it changes perms / locks the files while it is doing a backup.  Either
>  way, a file system backup is not the proper way to backup a pgsql
>  instance, unless it is combined with PITR recovery.
>
>  Best answer is to not let the backup agent hit the $PGDATA directory,
>  but rather to run a backup with pg_dump or pg_dumpall to some other
>  directory and have your backup agent back that file up.
>

problem is veritas which has a special kernel driver which can lock
any file even if it is in use by an application.  obviously, you do
not want to do raw file system backup of your database folder.

I would check out eSilo (disclaimer: I work at this company) for
backup solutions that are specialized towards databases.

merlin

В списке pgsql-general по дате отправления:

Предыдущее
От: Paul Silveira
Дата:
Сообщение: Re: shell script to populate array values
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Temp file space (Re: creating an index with tablespace on a dedicated filesystem)