From: | Hannes Erven <hannes(at)erven(dot)at> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | recovery_target_time and WAL fetch with streaming replication |
Date: | 2018-05-12 23:39:48 |
Message-ID: | db72ec7f-695b-1977-1f30-b422b475bab8@erven.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
what is Postgresql's strategy when to fetch WAL from the master while in
streaming replication, and could it be tweaked?
I'm using a physical streaming replication slave to have a database
lagging behind about one month behind the primary, by setting
"recovery_target_time" to the desired point in time.
This setting is periodically advanced by a cronjob to allow the replica
to roll forward. It's a 10.3-1 install on Debian.
It seems that as soon as the slave needs new WAL data to reach the
requested target time, it will connect to the primary and fetch /all/
new WAL the primary has available for the slave's slot - up to "now",
ignoring the recovery_target_time.
So in my setup, the slave will connect to the primary once per month,
and download the whole next month's WAL data at once.
I do not care on which instance WAL is kept until needed, but I'd really
prefer if the transfer (and disk space requirement!) would be more
evenly distributed.
One option of course would be to use some transfer mechanism external to
Postgresql... but so far I'm thinking there must be any easier way?
Thanks & best regards,
-hannes
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-05-13 06:23:55 | Re: recovery_target_time and WAL fetch with streaming replication |
Previous Message | Adrian Klaver | 2018-05-12 18:19:30 | Re: Domain based on TIMEZONE WITH TIME ZONE |