pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Ron <ronljohnsonjr@gmail.com>
To: pgsql-admin@lists.postgresql.org
Subject: Re: [External] Re: WAL Replication query
Date: Tue, 1 Nov 2022 08:49:52 -0500
Message-ID: <42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com> (raw)
In-Reply-To: <f78c361061449be8402922cd5ed7f5782f65aab1.camel@cybertec.at>
References: <CAKgGyB-SMT0RxeoifAfjkRx6RHEOgpn7sf8F_zD1DPsKydTu=w@mail.gmail.com>
	<88faef33e966796226022d6e7f3e32ad6c59fcfd.camel@cybertec.at>
	<MW4PR20MB4525ED0222DDE9FED0519D8FF3369@MW4PR20MB4525.namprd20.prod.outlook.com>
	<c1b6b89d6b89706acaeca9b4d45958f4739c4f28.camel@cybertec.at>
	<8f9e6c92-4daa-a543-6825-05a3503f4296@gmail.com>
	<f78c361061449be8402922cd5ed7f5782f65aab1.camel@cybertec.at>

On 11/1/22 08:34, Laurenz Albe wrote:
> On Tue, 2022-11-01 at 02:43 -0500, Ron wrote:
>> On 11/1/22 01:53, Laurenz Albe wrote:
>>> On Tue, 2022-11-01 at 06:44 +0000, Sacheen Birhade wrote:
>>>> If replication is in asynchronous then there will be data loss, right Laurenz?
>>> Why?  The data will perhaps show up on the standby a little later, but why is
>>> that data loss?  Remember that the question was about replication, and there
>>> was no mention of failover.
>>   No, the question was about a crash during replication: OP (not Sacheen, unless that person
>> is using two email addresses) explicitly asked "When the primary crashes  due an unforeseen
>> reason (what happens)?"
>>   
>>   If the two database systems are really busy, and especially if the network connection
>> isn't fast enough, async replication means there might be some transactions committed
>> on Primary which were queued for transmission, but hadn't yet made it to the Secondary, right?
> Right.  And how does that constitute data loss?  If you start the primary again, the transaction
> will be replicated just fine.  Now if you call it *data delay*, I would agree.

Primary has /crashed/, according to OP; it's not coming back any time soon.  
And thus you promote Secondary to be New Primary, and go about  your work.  
When the Old Primary comes back up (hours or days later), you do a 
pg_basebackup to make it the New Secondary.

-- 
Angular momentum makes the world go 'round.

view thread (15+ messages)  latest in thread

Message-ID: <42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com>
Permalink:  ../42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com/
Also on:    postgresql.org/message-id/42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: ronljohnsonjr@gmail.com, pgsql-admin@lists.postgresql.org
  Subject: Re: [External] Re: WAL Replication query
  In-Reply-To: <42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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