From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Switching XLog source from archive to streaming when primary available |
Date: | 2025-01-02 18:12:37 |
Message-ID: | 2D6CD551-8110-450B-BBD9-DAE64822304D@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 23 Mar 2024, at 14:22, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> IMHO, it makes sense to have something like replay_source_order if
> there's any use case that arises in future requiring the standby to
> intentionally switch to pg_wal or archive. But not as part of this
> feature.
IMO, it's vital part of a feature.
In my observation restore from archive is many orders of magnitude faster than streaming replication. Advanced archive tools employ compression (x6 to speed), download parallelism (x4), are not constrained be primary's network limits (x3) and disk limits, do not depend on complicated FEBE protocol, etc.
When I have to cope with lagging replica, almost always I kill walreceiver and tweak server readahead.
But there might be cases where you still have to attach replica ASAP. I can think of releasing replication slot, transiently failed archive network or storage.
Finally, one might want to have many primary connections: cascading replica might want to stream from any available host from the group of HA hosts.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-01-02 18:24:06 | POC: track vacuum/analyze cumulative time per relation |
Previous Message | Matheus Alcantara | 2025-01-02 17:53:15 | Re: read stream on amcheck |