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 :)
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 |