Message-ID: <44694.192.168.207.54.1432243144.squirrel@webmail.etecsa.cu>
In-Reply-To: 
 <CAHw75vsndJQWVWUxfikOuZDQJARFM19cFJoA_mND9_R-2KP0kg@mail.gmail.com>
References: 
 <CACER=P2-th_mciMaLDPu1eNge13fDmCHhjcrk-3MLc=ANJ_RzA@mail.gmail.com>
 <CANUg7LB_rZrXL0d+3UcrW8koiNgWO+jaAVTT8p52jcxxt1fSqg@mail.gmail.com>
 <CACER=P3H-y7XqHLj0txPbb6MT3cXhtjm-Rk9jym26ZDmQ2yrqQ@mail.gmail.com>
 <CAHw75vsndJQWVWUxfikOuZDQJARFM19cFJoA_mND9_R-2KP0kg@mail.gmail.com>
Date: Thu, 21 May 2015 16:19:04 -0500 (GMT+5)
Subject: Re: Postgres Synchronous replication
From: "Gilberto Castillo" <gilberto.castillo@etecsa.cu>
To: "Keith" <keith@keithf4.com>
Cc: "Ravi Krishna" <sravikrishna3@gmail.com>,
 "Payal Singh" <payal@omniti.com>,
 "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Reply-To: gilberto.castillo@etecsa.cu
User-Agent: SquirrelMail/1.4.8-5.el5_4.10
MIME-Version: 1.0
Importance: Normal
Content-Type: multipart/mixed; boundary="=tGIclW8g81588=imx3.etecsa.cu="
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

This is a multi-part message in MIME format.

--=tGIclW8g81588=imx3.etecsa.cu=
Content-Disposition: inline
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit


> On Thu, May 21, 2015 at 4:10 PM, Ravi Krishna <sravikrishna3@gmail.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@gmail.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

--=tGIclW8g81588=imx3.etecsa.cu=
Content-Type: text/plain
Content-Disposition: inline

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

--=tGIclW8g81588=imx3.etecsa.cu=
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


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

--=tGIclW8g81588=imx3.etecsa.cu=--