Content-Type: multipart/alternative;
 boundary="------------yfYQkqO3zJj4Ezo8KnpjGLjo"
Message-ID: <5fd4f533-a8f8-41d6-a79a-2bcd14c5a273@yahoo.co.uk>
Date: Tue, 19 Dec 2023 08:59:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Language: en-US
From: lejeczek <peljasz@yahoo.co.uk>
Subject: highest timeline xxx of the primary is behind recovery timeline -
 backup of the underlying filesystem
References: <5fd4f533-a8f8-41d6-a79a-2bcd14c5a273.ref@yahoo.co.uk>
Content-Length: 2063
Archived-At: 
 <https://www.postgresql.org/message-id/5fd4f533-a8f8-41d6-a79a-2bcd14c5a273%40yahoo.co.uk>
Precedence: bulk

This is a multi-part message in MIME format.
--------------yfYQkqO3zJj4Ezo8KnpjGLjo
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi guys.

I see these every now and again:

2023-12-19 08:43:17.311 CET [2494773] FATAL:  highest 
timeline 105 of the primary is behind recovery timeline 106

and the only thing I can think is a backup which in my case 
it a done with _libvirt_ as pgSQL cluster runs on Ubuntu VMs.
I'm not sure what exactly _virsh backup-begin_ does to the 
qcow2 and as a consequence, to the the FS in the VMs, but..
it would be good to have those backups.

Any thoughts & ideas shared are much appreciated.
I guess my first question would be -- if such VM backup 
might affect negatively pgSQL then, are there some tweaks, 
ways to harden pgSQL cluster internally for such scenarios?

many thanks, L.
--------------yfYQkqO3zJj4Ezo8KnpjGLjo
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <font size="2" face="Courier 10 Pitch">Hi guys.<br>
      <br>
      I see these every now and again:<br>
      <br>
      2023-12-19 08:43:17.311 CET [2494773] FATAL:  highest timeline 105
      of the primary is behind recovery timeline 106<br>
      <br>
      and the only thing I can think is a backup which in my case it a
      done with _libvirt_ as pgSQL cluster runs on Ubuntu VMs.<br>
      I'm not sure what exactly _virsh backup-begin_ does to the qcow2
      and as a consequence, to the the FS in the VMs, but..<br>
      it would be good to have those backups.<br>
      <br>
      Any thoughts &amp; ideas shared are much appreciated.<br>
      I guess my first question would be -- if such VM backup might
      affect negatively pgSQL then, are there some tweaks, ways to
      harden pgSQL cluster internally for such scenarios?<br>
      <br>
      many thanks, L.<br>
    </font>
  </body>
</html>

--------------yfYQkqO3zJj4Ezo8KnpjGLjo--