[11.6] WALs recovery ordering with Restore Command - timelines

From: Pavel Suderevsky <psuderevsky(at)gmail(dot)com>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: [11.6] WALs recovery ordering with Restore Command - timelines
Date: 2019-11-25 20:26:05
Message-ID: CAEBTBzt9Enh8UJYAWWHj4CVj6YgW87mdWwW9pEEXjhzSW3cupg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

PostgreSQL 11.6
Centos 7.6
pgBackrest 2.19

Case:
Master is on timeline 15 while Standby that should be synchronized with
Master as a hot standby is on timeline 13. WALs to be obtained from archive.

recovery.conf:
>primary_conninfo = 'user=usename host=10.10.10.3 port=5432 sslmode=prefer
application_name=pg2'
>recovery_target_timeline = 'latest'
>restore_command = '/usr/bin/pgbackrest --stanza=platform archive-get %f
"%p" --log-level-console info'
>standby_mode = 'on'

Standby recovery is done like that:
1. try restore 0000000F00000A27000000E5
2. unable to find 0000000F00000A27000000E5 in the archive
3. try restore 0000000E00000A27000000E5
4. found 0000000E00000A27000000E5 in the archive
-- trying next WAL for BOTH timelines
1. try restore 0000000F00000A27000000E6
2. unable to find 0000000F00000A27000000E6 in the archive
3. try restore 0000000E00000A27000000E6
4. found 0000000E00000A27000000E6 in the archive

Why does Postgres restore WALs not in a timelines order? First 13, then 14,
then 15. Up to timeline switch position. WALs it try to restore for the
latest timeline are deliberately not yet exist. It leads to terrible
recovery performance because of long "unable to find" operations.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Yessica Brinkmann 2019-11-25 21:38:37 Re: I think that my data is saved correctly, but when printing again, other data appears
Previous Message Bob Jolliffe 2019-11-25 16:46:56 Re: casting Bangla characters to NUMERIC