Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opreR-0002YF-6i for pgsql-admin@arkaria.postgresql.org; Tue, 01 Nov 2022 13:49:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1opreQ-0001ga-2x for pgsql-admin@arkaria.postgresql.org; Tue, 01 Nov 2022 13:49:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opreP-0001gD-MR for pgsql-admin@lists.postgresql.org; Tue, 01 Nov 2022 13:49:57 +0000 Received: from mail-oa1-x32.google.com ([2001:4860:4864:20::32]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1opreN-0007A8-3A for pgsql-admin@lists.postgresql.org; Tue, 01 Nov 2022 13:49:56 +0000 Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-13ae8117023so16827001fac.9 for ; Tue, 01 Nov 2022 06:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=uNXv34GCPynNXRjTkJ5zj6mbdIT5WnRUPjnCVukeVC4=; b=kSZUnhONdKd1s72qhYC1TEPiqk9d4sp/qVvQ+ggR/9bAmNYZEYRY5li0UVwmPHNbo9 J2NO9eDbFs4nc0noPUfKelRT7Y+KsSXSFQDIoDeIITE0zf3oMA2FDADbrN/7WVEqhwFP cwIY7KfXRgs1FZw7/3q6ketERuKeYuSzihBBF9N9n4kGnF/X1V6KzpMfn+0UC8qEjrj/ b+P8RRT1AzUChTJ0OMofCxV6l5HkqdhEokB1UndnoBwlPOMQU0sOVqgjg5a4Ej/GiWD1 hPsJWIdTRqmUdoV8dltXlKHQiNK8d1xGJSRXES3CTkaaTRdogwenuNwKWGP5m7+GDJzg TPag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=uNXv34GCPynNXRjTkJ5zj6mbdIT5WnRUPjnCVukeVC4=; b=QWZjmnfDK6d+jPdOmZd0bXxqWzPzRf15B0HyLCjwV26wGSPfJ2g+WodN5buy6iEeGY WdpGgc22dXbl+IwIv7QadhdV0vlSVkQILI0eSgHL1l67njFa18SXPMzsygL82y1mW36n R9ZeJ8j8zzAJt5OnsefeCI4a7RH+wrj7+5cHB9LKB8m9/osFjR0JXiXY66cF9L8Fs8XU Y8wc5IPQepNM+8ji50qBN2qNzC3IKQmZ2WxrlH8Q6owbUAicj2oi/Yz0PV0cPlwTuTpc rEGdBNgN151/fBN+pU/jgiCnAgwwS+M6nvpl5mS/xdlbu8jo3wwc2xQ2w7iFq8SvO6Kr st2w== X-Gm-Message-State: ACrzQf1Ae9ROu2IAlugr8mMvAHnpMkKLad1lDy9vD00EWZEG9RMS7+go LCwvUE4ZqvSM0Jh+iN6OUNDuUOlZsac= X-Google-Smtp-Source: AMsMyM64hF96k2mPJ2iR8o7r5p2jmUCm2REgeguAl/Pl3eUJBUrqqNzwi5FH0YzOQGoz4lwgyx8T1g== X-Received: by 2002:a05:6870:4798:b0:12c:989b:a3b7 with SMTP id c24-20020a056870479800b0012c989ba3b7mr20617620oaq.181.1667310593893; Tue, 01 Nov 2022 06:49:53 -0700 (PDT) Received: from [192.168.88.10] (ip68-11-68-85.no.no.cox.net. [68.11.68.85]) by smtp.googlemail.com with ESMTPSA id y15-20020a544d8f000000b00354d9b9f6b4sm3361167oix.27.2022.11.01.06.49.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 06:49:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------3PU0Gm5w5r0lJRXwmPI0Cogz" Message-ID: <42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com> Date: Tue, 1 Nov 2022 08:49:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [External] Re: WAL Replication query Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <88faef33e966796226022d6e7f3e32ad6c59fcfd.camel@cybertec.at> <8f9e6c92-4daa-a543-6825-05a3503f4296@gmail.com> From: Ron In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------3PU0Gm5w5r0lJRXwmPI0Cogz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. --------------3PU0Gm5w5r0lJRXwmPI0Cogz Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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.
--------------3PU0Gm5w5r0lJRXwmPI0Cogz--