From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
---|---|
To: | "Aggarwal, Ajay" <aaggarwal(at)verizon(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: replication timeout in pg_basebackup |
Date: | 2014-03-10 05:42:18 |
Message-ID: | CAJrrPGcFfjqBMSLrKvze7D-dA+3kMciFpRzYxa4_Cs9PB+hifg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Mar 10, 2014 at 12:52 PM, Aggarwal, Ajay <aaggarwal(at)verizon(dot)com>wrote:
> Our environment: Postgres version 9.2.2 running on CentOS 6.4
>
> Our backups using pg_basebackup are frequently failing with following error
>
> "pg_basebackup: could not send feedback packet: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request."
>
> We are invoking pg_basebackup with these arguments : pg_basebackup -D backup_dir -X stream -l backup_dir
>
> In postgres logs we see this log message "terminating walsender process
> due to replication timeout".
>
> Our replication timeout is default 60 seconds. If we increase the
> replication time to say 180 seconds, we see better results but backups
> still fail occasionally.
>
> Running strace on pg_basebackup process, we see that the fsync() call
> takes significant time and could be responsible for causing this timeout in
> postgres.
>
Use the pg_test_fsync utility which is available in postgresql contrib
module to test your system sync methods performance.
> Has anybody else run into the same issue? Is there a way to run
> pg_basebackup without fsync() ?
>
As of now there is no such options available, I feel it is better to find
why the sync is taking time?
Regards,
Hari Babu
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2014-03-10 06:58:26 | Re: libpq - lack of support to set the fetch size |
Previous Message | Aggarwal, Ajay | 2014-03-10 01:52:33 | replication timeout in pg_basebackup |