Re: Postgres 9.1 Synchronous Replication and stuck queries during sync repl setup

From: Manoj Govindassamy <manoj(at)nimblestorage(dot)com>
To: Gabriele Bartolini <Gabriele(dot)Bartolini(at)2ndQuadrant(dot)it>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Postgres 9.1 Synchronous Replication and stuck queries during sync repl setup
Date: 2012-06-06 16:16:16
Message-ID: ADD354851455FC44A5D8923AD5152DE307A0FA90@coloex01.nimblestorage.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general


Gabriele,

Thanks for the quick reply.

> That's not necessary. Usually you do this only the first time you set
> it up, then take advantage of the wal_keep_segments on the master and
> allow the standby to resync.

we are not sure about when the standby will come again and sync with master. also, we have space constraints on the master and can't keep indefinite segments.

> This behaviour is perfectly fine. Until the master and the standby are
> in sync,

But, even after the standby came to sync mode, those statements that are executed between (1) and (2) remain stuck only. they don't complete at all.

> Then uncomment the 'synchronous_standby_names' line on the
> master and issue a reload.

doesn't any change to 'synchronous_standby_names' need a server restart ?? Just a reload config command is sufficient here ?

yes, all the servers are in same LAN. Thanks for your time.

- manoj

________________________________________
From: pgsql-admin-owner(at)postgresql(dot)org [pgsql-admin-owner(at)postgresql(dot)org] on behalf of Gabriele Bartolini [Gabriele(dot)Bartolini(at)2ndQuadrant(dot)it]
Sent: Wednesday, June 06, 2012 8:51 AM
To: Manoj Govindassamy
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] Postgres 9.1 Synchronous Replication and stuck queries during sync repl setup

Hi,

On Wed, 6 Jun 2012 14:55:15 +0000, Manoj Govindassamy
<manoj(at)nimblestorage(dot)com> wrote:
> PG Slave gets fresh backup from PG master using pg_backup utility
> everytime before it starts up

That's not necessary. Usually you do this only the first time you set
it up, then take advantage of the wal_keep_segments on the master and
allow the standby to resync.

> A. I need to know why PG master started accepting connections at (1)
> and still NOT able to fully commit the transactions. Statements that
> are executed after (3) are not seeing this problem.

This behaviour is perfectly fine. Until the master and the standby are
in sync, given that you set the standby to be the synchronous one, the
master MUST wait until the standby writes on disk the transaction
information.

I suggest that first you remove the standby server from the list of
synchronous servers by commenting the 'synchronous_standby_names' line
and wait until the standby catches up (asynchronous streaming
replication). Then uncomment the 'synchronous_standby_names' line on the
master and issue a reload. From that moment on you will have synchronous
streaming replication in place.

Cheers,
Gabriele

P.S.: I took it for granted that the two servers are in the same LAN.
--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
Gabriele(dot)Bartolini(at)2ndQuadrant(dot)it - www.2ndQuadrant.it

--
Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2012-06-06 16:24:35 Re: postgres block size alignment with filesystem block size
Previous Message Mike Broers 2012-06-06 15:54:40 postgres block size alignment with filesystem block size

Browse pgsql-general by date

  From Date Subject
Next Message Benson Jin 2012-06-06 16:20:06 Need help in transferring FP to Int64 DateTime
Previous Message Frank Lanitz 2012-06-06 15:58:28 Re: pg_database_size differs from df -s