Re: Postgres Synchronous replication

From: Keith <keith(at)keithf4(dot)com>
To: gilberto(dot)castillo(at)etecsa(dot)cu
Cc: Ravi Krishna <sravikrishna3(at)gmail(dot)com>, Payal Singh <payal(at)omniti(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Postgres Synchronous replication
Date: 2015-05-21 20:41:09
Message-ID: CAHw75vv_P6rDKK3q-qp9MfM+Es299ZGty20OxU2Tj1Dogi=JwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Thu, May 21, 2015 at 5:19 PM, Gilberto Castillo <
gilberto(dot)castillo(at)etecsa(dot)cu> wrote:

>
>
> > On Thu, May 21, 2015 at 4:10 PM, Ravi Krishna <sravikrishna3(at)gmail(dot)com>
> > wrote:
> >
> >>
> >> AFAIK the commit on master happens only after it receives ack from the
> >>> slave. This is how synchronous replication ensures that the slave is'in
> >>> sync'.
> >>>
> >>
> >>
> >> If that is the case , then why does PG find it impossible to sync back
> >> with the primary after a crash.
> >> Other products offering similar technology do not have this issue.
> >>
> >> In my opinion this is quite a serious limitation with PG replication.
> >> Every time the primary crashes and the business continues with the
> >> promotion of standby as the new primary, the crashed server has to be
> >> reinitialized for the set up of the replication.
> >>
> >>
> >>
> >>>
> >>> On Thu, May 21, 2015 at 3:56 PM, Ravi Krishna <sravikrishna3(at)gmail(dot)com
> >
> >>> wrote:
> >>>
> >>>> I want to understand how PG sync replication works. This is what I
> >>>> know
> >>>> (assuming two node sync replication)
> >>>>
> >>>> 1 - Application issues commit.
> >>>> 2 - PG commits the transaction locally on the primary server.
> >>>> 3 - At this stage the application has not got the commit indication
> >>>> back.
> >>>> 4 - PG transmits the transaction from the local to the remote server.
> >>>> 5 - Remote server sends back acknowledgement
> >>>> 6 - The app gets commit ack back.
> >>>>
> >>>> So this means, between step 2 and step 6, the app is not aware that
> >>>> the
> >>>> transaction has already been committed.
> >>>> This is the reason why, in the event of server crashing between step 2
> >>>> and step 6, and the remote takes over as the
> >>>> new primary, the crashed server can not restart as standby and the
> >>>> only
> >>>> option is to recreate the db from the remote
> >>>> server (which is now acting as the primary).
> >>>>
> >>>> Am I correct in the understanding?
> >>>>
> >>>> One more question: In Step 5, does the remote harden the transaction
> >>>> on
> >>>> the disk, or merely receives the transaction in the log buffer and it
> >>>> sends
> >>>> back ACK to the local server.
> >>>>
> >>>> Thanks
> >>>>
> >>>
> >>>
> >>
> >
> > This issue has been address with pg_rewind in the upcoming 9.5 major
> > version release
> >
> > http://hlinnaka.iki.fi/2015/03/23/pg_rewind-in-postgresql-9-5/
>
> pg_rewind is used 9.3 onwards
>
> Saludos,
> Gilberto Castillo
> ETECSA, La Habana, Cuba
>
> ---
> This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE
> running at host imx3.etecsa.cu
> Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>
>
>
True, but it's included in the official release as of 9.5 :)

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Keith 2015-05-21 20:44:35 Re: Postgres Synchronous replication
Previous Message Scott Ribe 2015-05-21 20:29:59 Re: Postgres Synchronous replication