pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedPostgres Synchronous replication
13+ messages / 7 participants
[nested] [flat]
* Postgres Synchronous replication
@ 2015-05-21 19:56 Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
0 siblings, 1 reply; 13+ messages in thread
From: Ravi Krishna @ 2015-05-21 19:56 UTC (permalink / raw)
To: pgsql-admin
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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
@ 2015-05-21 20:01 ` Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:12 ` Re: Postgres Synchronous replication John Scalia <jayknowsunix@gmail.com>
0 siblings, 2 replies; 13+ messages in thread
From: Payal Singh @ 2015-05-21 20:01 UTC (permalink / raw)
To: Ravi Krishna <sravikrishna3@gmail.com>; +Cc: pgsql-admin
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'.
Payal Singh,
Database Administrator,
OmniTI Computer Consulting Inc.
Phone: 240.646.0770 x 253
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
>
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
@ 2015-05-21 20:10 ` Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:13 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
2015-05-21 20:29 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
1 sibling, 2 replies; 13+ messages in thread
From: Ravi Krishna @ 2015-05-21 20:10 UTC (permalink / raw)
To: Payal Singh <payal@omniti.com>; +Cc: pgsql-admin
> 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
>>
>
>
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
@ 2015-05-21 20:13 ` Keith <keith@keithf4.com>
2015-05-21 21:19 ` Re: Postgres Synchronous replication Gilberto Castillo <gilberto.castillo@etecsa.cu>
1 sibling, 1 reply; 13+ messages in thread
From: Keith @ 2015-05-21 20:13 UTC (permalink / raw)
To: Ravi Krishna <sravikrishna3@gmail.com>; +Cc: Payal Singh <payal@omniti.com>; pgsql-admin
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/
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:13 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
@ 2015-05-21 21:19 ` Gilberto Castillo <gilberto.castillo@etecsa.cu>
2015-05-21 20:41 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
0 siblings, 1 reply; 13+ messages in thread
From: Gilberto Castillo @ 2015-05-21 21:19 UTC (permalink / raw)
To: Keith <keith@keithf4.com>; +Cc: Ravi Krishna <sravikrishna3@gmail.com>; Payal Singh <payal@omniti.com>; pgsql-admin
> 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
---
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;
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:13 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
2015-05-21 21:19 ` Re: Postgres Synchronous replication Gilberto Castillo <gilberto.castillo@etecsa.cu>
@ 2015-05-21 20:41 ` Keith <keith@keithf4.com>
0 siblings, 0 replies; 13+ messages in thread
From: Keith @ 2015-05-21 20:41 UTC (permalink / raw)
To: gilberto.castillo@etecsa.cu; +Cc: Ravi Krishna <sravikrishna3@gmail.com>; Payal Singh <payal@omniti.com>; pgsql-admin
On Thu, May 21, 2015 at 5:19 PM, Gilberto Castillo <
gilberto.castillo@etecsa.cu> wrote:
>
>
> > 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
>
> ---
> 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 :)
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
@ 2015-05-21 20:29 ` Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-21 20:44 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
1 sibling, 1 reply; 13+ messages in thread
From: Scott Ribe @ 2015-05-21 20:29 UTC (permalink / raw)
To: Ravi Krishna <sravikrishna3@gmail.com>; +Cc: pgsql-admin
On May 21, 2015, at 2:10 PM, Ravi Krishna <sravikrishna3@gmail.com> wrote:
>
> Every time the primary crashes…
While I agree it’s a limitation, in 14 years I’ve not seen PG crash once.
--
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:29 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
@ 2015-05-21 20:44 ` Keith <keith@keithf4.com>
2015-05-21 21:00 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Keith @ 2015-05-21 20:44 UTC (permalink / raw)
To: Scott Ribe <scott_ribe@elevated-dev.com>; +Cc: Ravi Krishna <sravikrishna3@gmail.com>; pgsql-admin
On Thu, May 21, 2015 at 4:29 PM, Scott Ribe <scott_ribe@elevated-dev.com>
wrote:
> On May 21, 2015, at 2:10 PM, Ravi Krishna <sravikrishna3@gmail.com> wrote:
> >
> > Every time the primary crashes…
>
> While I agree it’s a limitation, in 14 years I’ve not seen PG crash once.
>
>
> --
> Scott Ribe
> scott_ribe@elevated-dev.com
> http://www.elevated-dev.com/
> https://www.linkedin.com/in/scottribe/
> (303) 722-0567 voice
>
>
>
>
>
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>
It's not just an issue of crashing, it's an issue of failover in general,
which happens quite often in high-availability scenarios. Unless a second
slave is available, it can be a bit nerve-racking after you failover due to
some network or system issue, you've only got a single postgres instance up
for your application until you rebuild the old one.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:29 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-21 20:44 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
@ 2015-05-21 21:00 ` Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 21:02 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
0 siblings, 1 reply; 13+ messages in thread
From: Ravi Krishna @ 2015-05-21 21:00 UTC (permalink / raw)
To: Keith <keith@keithf4.com>; +Cc: Scott Ribe <scott_ribe@elevated-dev.com>; pgsql-admin
>
> >>
>> Every time the primary crashes...
>
>
> >
>> While I agree it's a limitation, in 14 years I've not seen PG crash once
>
>
What about machine crashing? With Intel/Linux based commodity hardware, we
go with the assumption that machines will fail and indeed they do. For our
DB2 and Oracle servers, it is a breeze to re-integrate the failed server.
Anyhow pg_rewind seem to solve that issue.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:29 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-21 20:44 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
2015-05-21 21:00 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
@ 2015-05-21 21:02 ` Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-22 14:27 ` Re: Postgres Synchronous replication Felipe Santos <felipepts@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Scott Ribe @ 2015-05-21 21:02 UTC (permalink / raw)
To: Ravi Krishna <sravikrishna3@gmail.com>; +Cc: pgsql-admin
On May 21, 2015, at 3:00 PM, Ravi Krishna <sravikrishna3@gmail.com> wrote:
>
> What about machine crashing?
Hasn’t been a problem. But of course it’s a numbers game, and if you have enough machines in play, you will certainly have failures.
--
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:29 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-21 20:44 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
2015-05-21 21:00 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 21:02 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
@ 2015-05-22 14:27 ` Felipe Santos <felipepts@gmail.com>
2015-05-22 14:38 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Felipe Santos @ 2015-05-22 14:27 UTC (permalink / raw)
To: Scott Ribe <scott_ribe@elevated-dev.com>; +Cc: Ravi Krishna <sravikrishna3@gmail.com>; pgsql-admin
"does the remote harden the transaction on the disk"
Yes, but it is surely written to the LOG FILES, there's no warranty that it
has already been written to the DATA FILES, although that's not a problem,
since LOG FILES are designed to be played forward in the case of a server
crash, replaying the commited transactions to the data files.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:29 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-21 20:44 ` Re: Postgres Synchronous replication Keith <keith@keithf4.com>
2015-05-21 21:00 ` Re: Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 21:02 ` Re: Postgres Synchronous replication Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-22 14:27 ` Re: Postgres Synchronous replication Felipe Santos <felipepts@gmail.com>
@ 2015-05-22 14:38 ` Ravi Krishna <sravikrishna3@gmail.com>
0 siblings, 0 replies; 13+ messages in thread
From: Ravi Krishna @ 2015-05-22 14:38 UTC (permalink / raw)
To: Felipe Santos <felipepts@gmail.com>; +Cc: Scott Ribe <scott_ribe@elevated-dev.com>; pgsql-admin
> "does the remote harden the transaction on the disk"
>
> Yes, but it is surely written to the LOG FILES, there's no warranty that it
> has already been written to the DATA FILES, although that's not a problem,
> since LOG FILES are designed to be played forward in the case of a server
> crash, replaying the commited transactions to the data files.
By hardening I meant only the WAL logs and not the data files.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Postgres Synchronous replication
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Re: Postgres Synchronous replication Payal Singh <payal@omniti.com>
@ 2015-05-21 20:12 ` John Scalia <jayknowsunix@gmail.com>
1 sibling, 0 replies; 13+ messages in thread
From: John Scalia @ 2015-05-21 20:12 UTC (permalink / raw)
To: Payal Singh <payal@omniti.com>; +Cc: Ravi Krishna <sravikrishna3@gmail.com>; pgsql-admin
Payal is correct. The correct sequence would 1, 4, 5, 2, 3, 6.
That's how I see it anyway.
On Thu, May 21, 2015 at 1:01 PM, Payal Singh <payal@omniti.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'.
>
> Payal Singh,
> Database Administrator,
> OmniTI Computer Consulting Inc.
> Phone: 240.646.0770 x 253
>
> 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
>>
>
>
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2015-05-22 14:38 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-05-21 19:56 Postgres Synchronous replication Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:01 ` Payal Singh <payal@omniti.com>
2015-05-21 20:10 ` Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:13 ` Keith <keith@keithf4.com>
2015-05-21 21:19 ` Gilberto Castillo <gilberto.castillo@etecsa.cu>
2015-05-21 20:41 ` Keith <keith@keithf4.com>
2015-05-21 20:29 ` Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-21 20:44 ` Keith <keith@keithf4.com>
2015-05-21 21:00 ` Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 21:02 ` Scott Ribe <scott_ribe@elevated-dev.com>
2015-05-22 14:27 ` Felipe Santos <felipepts@gmail.com>
2015-05-22 14:38 ` Ravi Krishna <sravikrishna3@gmail.com>
2015-05-21 20:12 ` John Scalia <jayknowsunix@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox