On Tue, Feb 20, 2024 at 11:54 AM Japin Li <japi...@hotmail.com> wrote:
>
>
> On Tue, 20 Feb 2024 at 13:40, Bharath Rupireddy
> <bharath.rupireddyforpostg...@gmail.com> wrote:
> > On Mon, Feb 19, 2024 at 8:25 PM Japin Li <japi...@hotmail.com> wrote:
> >> [2]
> >> +# Ensure checkpoint doesn't come in our way
> >> +$primary->append_conf('postgresql.conf', qq(
> >> + min_wal_size = 2MB
> >> + max_wal_size = 1GB
> >> + checkpoint_timeout = 1h
> >> + autovacuum = off
> >> +));
> >>
> >> Keeping the same indentation might be better.
> >
> > The autovacuum line looks mis-indented in the patch file. However, I
> > now ran src/tools/pgindent/perltidyrc
> > src/test/recovery/t/041_wal_source_switch.pl on it.
> >
>
> Thanks for updating the patch. It seems still with the wrong indent.
Thanks. perltidyrc didn't complain about anything on v19. However, I
kept the alignment same as other TAP tests for multi-line append_conf.
If that's not correct, I'll leave it to the committer to decide. PSA
v20 patch.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From beea9f0b8bbc76bb48dd1a5d64a5b52bafd09e6f Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Tue, 20 Feb 2024 07:31:29 +0000
Subject: [PATCH v20] Allow standby to switch WAL source from archive to
streaming
A standby typically switches to streaming replication (get WAL
from primary), only when receive from WAL archive finishes (no
more WAL left there) or fails for any reason. Reading WAL from
archive may not always be as efficient and fast as reading from
primary. This can be due to the differences in disk types, IO
costs, network latencies etc.. All of these can impact the
recovery performance on standby and increase the replication lag
on primary. In addition, the primary keeps accumulating WAL needed
for the standby while the standby reads WAL from archive because
the standby replication slot stays inactive. To avoid these
problems, one can use this parameter to make standby switch to
stream mode sooner.
This feature adds a new GUC that specifies amount of time after
which standby attempts to switch WAL source from WAL archive to
streaming replication (getting WAL from primary). However, standby
exhausts all the WAL present in pg_wal before switching. If
standby fails to switch to stream mode, it falls back to archive
mode.
Author: Bharath Rupireddy
Reviewed-by: Cary Huang, Nathan Bossart
Reviewed-by: Kyotaro Horiguchi, SATYANARAYANA NARLAPURAM
Discussion: https://www.postgresql.org/message-id/CAHg+QDdLmfpS0n0U3U+e+dw7X7jjEOsJJ0aLEsrtxs-tUyf5Ag@mail.gmail.com
---
doc/src/sgml/config.sgml | 48 ++++++++
doc/src/sgml/high-availability.sgml | 15 ++-
src/backend/access/transam/xlogrecovery.c | 115 ++++++++++++++++--
src/backend/utils/misc/guc_tables.c | 12 ++
src/backend/utils/misc/postgresql.conf.sample | 4 +
src/include/access/xlogrecovery.h | 1 +
src/test/recovery/meson.build | 1 +
src/test/recovery/t/041_wal_source_switch.pl | 110 +++++++++++++++++
8 files changed, 287 insertions(+), 19 deletions(-)
create mode 100644 src/test/recovery/t/041_wal_source_switch.pl
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index ffd711b7f2..2fbf1ad6e1 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4872,6 +4872,54 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
</listitem>
</varlistentry>
+ <varlistentry id="guc-streaming-replication-retry-interval" xreflabel="streaming_replication_retry_interval">
+ <term><varname>streaming_replication_retry_interval</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>streaming_replication_retry_interval</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specifies amount of time after which standby attempts to switch WAL
+ source from archive to streaming replication (i.e., getting WAL from
+ primary). However, the standby exhausts all the WAL present in
+ <filename>pg_wal</filename> directory before switching. If the standby
+ fails to switch to stream mode, it falls back to archive mode. If this
+ parameter value is specified without units, it is taken as
+ milliseconds. Default is <literal>5min</literal>. With a lower value
+ for this parameter, the standby makes frequent WAL source switch
+ attempts. To avoid this, it is recommended to set a reasonable value.
+ A setting of <literal>0</literal> disables the feature. When disabled,
+ the standby typically switches to stream mode only after receiving WAL
+ from archive finishes (i.e., no more WAL left there) or fails for any
+ reason. This parameter can only be set in the
+ <filename>postgresql.conf</filename> file or on the server command
+ line.
+ </para>
+ <note>
+ <para>
+ Standby may not always attempt to switch source from WAL archive to
+ streaming replication at exact
+ <varname>streaming_replication_retry_interval</varname> intervals. For
+ example, if the parameter is set to <literal>1min</literal> and
+ fetching WAL file from archive takes about <literal>2min</literal>,
+ then the source switch attempt happens for the next WAL file after
+ current WAL file fetched from archive is fully applied.
+ </para>
+ </note>
+ <para>
+ Reading WAL from archive may not always be as efficient and fast as
+ reading from primary. This can be due to the differences in disk types,
+ IO costs, network latencies etc.. All of these can impact the recovery
+ performance on standby and increase the replication lag on primary. In
+ addition, the primary keeps accumulating WAL needed for the standby
+ while the standby reads WAL from archive because the standby
+ replication slot stays inactive. To avoid these problems, one can use
+ this parameter to make standby switch to stream mode sooner.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-recovery-min-apply-delay" xreflabel="recovery_min_apply_delay">
<term><varname>recovery_min_apply_delay</varname> (<type>integer</type>)
<indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 236c0af65f..ab2e4293bf 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -628,12 +628,15 @@ protocol to make nodes agree on a serializable transactional order.
In standby mode, the server continuously applies WAL received from the
primary server. The standby server can read WAL from a WAL archive
(see <xref linkend="guc-restore-command"/>) or directly from the primary
- over a TCP connection (streaming replication). The standby server will
- also attempt to restore any WAL found in the standby cluster's
- <filename>pg_wal</filename> directory. That typically happens after a server
- restart, when the standby replays again WAL that was streamed from the
- primary before the restart, but you can also manually copy files to
- <filename>pg_wal</filename> at any time to have them replayed.
+ over a TCP connection (streaming replication) or attempt to switch to
+ streaming replication after reading from archive when
+ <xref linkend="guc-streaming-replication-retry-interval"/> parameter is
+ set. The standby server will also attempt to restore any WAL found in the
+ standby cluster's <filename>pg_wal</filename> directory. That typically
+ happens after a server restart, when the standby replays again WAL that was
+ streamed from the primary before the restart, but you can also manually
+ copy files to <filename>pg_wal</filename> at any time to have them
+ replayed.
</para>
<para>
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 0bb472da27..7f83ea22a1 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -91,6 +91,7 @@ TimestampTz recoveryTargetTime;
const char *recoveryTargetName;
XLogRecPtr recoveryTargetLSN;
int recovery_min_apply_delay = 0;
+int streaming_replication_retry_interval = 300000;
/* options formerly taken from recovery.conf for XLOG streaming */
char *PrimaryConnInfo = NULL;
@@ -297,6 +298,8 @@ bool reachedConsistency = false;
static char *replay_image_masked = NULL;
static char *primary_image_masked = NULL;
+/* Holds the timestamp at which standby switched WAL source to archive */
+static TimestampTz switched_to_archive_at = 0;
/*
* Shared-memory state for WAL recovery.
@@ -440,6 +443,8 @@ static bool HotStandbyActiveInReplay(void);
static void SetCurrentChunkStartTime(TimestampTz xtime);
static void SetLatestXTime(TimestampTz xtime);
+static bool SwitchWALSourceToPrimary(void);
+
/*
* Initialization of shared memory for WAL recovery
*/
@@ -3526,8 +3531,11 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
bool nonblocking)
{
static TimestampTz last_fail_time = 0;
+ static bool canSwitchSource = false;
+ bool switchSource = false;
TimestampTz now;
bool streaming_reply_sent = false;
+ XLogSource readFrom;
/*-------
* Standby mode is implemented by a state machine:
@@ -3547,6 +3555,12 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
* those actions are taken when reading from the previous source fails, as
* part of advancing to the next state.
*
+ * Try reading WAL from primary after being in XLOG_FROM_ARCHIVE state for
+ * at least streaming_replication_retry_interval milliseconds. However,
+ * exhaust all the WAL present in pg_wal before switching. If successful,
+ * the state machine moves to XLOG_FROM_STREAM state, otherwise it falls
+ * back to XLOG_FROM_ARCHIVE state.
+ *
* If standby mode is turned off while reading WAL from stream, we move
* to XLOG_FROM_ARCHIVE and reset lastSourceFailed, to force fetching
* the files (which would be required at end of recovery, e.g., timeline
@@ -3570,19 +3584,20 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
bool startWalReceiver = false;
/*
- * First check if we failed to read from the current source, and
- * advance the state machine if so. The failure to read might've
+ * First check if we failed to read from the current source or we
+ * intentionally want to switch the source from archive to primary,
+ * and advance the state machine if so. The failure to read might've
* happened outside this function, e.g when a CRC check fails on a
* record, or within this loop.
*/
- if (lastSourceFailed)
+ if (lastSourceFailed || switchSource)
{
/*
* Don't allow any retry loops to occur during nonblocking
- * readahead. Let the caller process everything that has been
- * decoded already first.
+ * readahead if we failed to read from the current source. Let the
+ * caller process everything that has been decoded already first.
*/
- if (nonblocking)
+ if (nonblocking && lastSourceFailed)
return XLREAD_WOULDBLOCK;
switch (currentSource)
@@ -3714,9 +3729,27 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
}
if (currentSource != oldSource)
- elog(DEBUG2, "switched WAL source from %s to %s after %s",
- xlogSourceNames[oldSource], xlogSourceNames[currentSource],
- lastSourceFailed ? "failure" : "success");
+ {
+ /* Save the timestamp at which we are switching to archive */
+ if (currentSource == XLOG_FROM_ARCHIVE)
+ switched_to_archive_at = GetCurrentTimestamp();
+
+ ereport(DEBUG1,
+ errmsg_internal("switched WAL source from %s to %s after %s",
+ xlogSourceNames[oldSource],
+ xlogSourceNames[currentSource],
+ (switchSource ? "timeout" : (lastSourceFailed ? "failure" : "success"))));
+
+ /* Reset the WAL source switch state */
+ if (switchSource)
+ {
+ Assert(canSwitchSource);
+ Assert(currentSource == XLOG_FROM_STREAM);
+ Assert(oldSource == XLOG_FROM_ARCHIVE);
+ switchSource = false;
+ canSwitchSource = false;
+ }
+ }
/*
* We've now handled possible failure. Try to read from the chosen
@@ -3745,13 +3778,23 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
if (randAccess)
curFileTLI = 0;
+ /* See if we can switch WAL source to streaming */
+ if (!canSwitchSource)
+ canSwitchSource = SwitchWALSourceToPrimary();
+
/*
* Try to restore the file from archive, or read an existing
- * file from pg_wal.
+ * file from pg_wal. However, before switching WAL source to
+ * streaming, give it a chance to read all the WAL from
+ * pg_wal.
*/
- readFile = XLogFileReadAnyTLI(readSegNo, DEBUG2,
- currentSource == XLOG_FROM_ARCHIVE ? XLOG_FROM_ANY :
- currentSource);
+ if (canSwitchSource)
+ readFrom = XLOG_FROM_PG_WAL;
+ else
+ readFrom = currentSource == XLOG_FROM_ARCHIVE ?
+ XLOG_FROM_ANY : currentSource;
+
+ readFile = XLogFileReadAnyTLI(readSegNo, DEBUG2, readFrom);
if (readFile >= 0)
return XLREAD_SUCCESS; /* success! */
@@ -3759,6 +3802,14 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
* Nope, not found in archive or pg_wal.
*/
lastSourceFailed = true;
+
+ /*
+ * Read all the WAL in pg_wal. Now ready to switch to
+ * streaming.
+ */
+ if (canSwitchSource)
+ switchSource = true;
+
break;
case XLOG_FROM_STREAM:
@@ -3989,6 +4040,44 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
return XLREAD_FAIL; /* not reached */
}
+/*
+ * Check if standby can make an attempt to read WAL from primary after reading
+ * from archive for at least a configurable duration.
+ *
+ * Reading WAL from archive may not always be as efficient and fast as reading
+ * from primary. This can be due to the differences in disk types, IO costs,
+ * network latencies etc.. All of these can impact the recovery performance on
+ * standby and increase the replication lag on primary. In addition, the
+ * primary keeps accumulating WAL needed for the standby while the standby
+ * reads WAL from archive because the standby replication slot stays inactive.
+ * To avoid these problems, the standby will try to switch to stream mode
+ * sooner.
+ */
+static bool
+SwitchWALSourceToPrimary(void)
+{
+ TimestampTz now;
+
+ if (streaming_replication_retry_interval <= 0 ||
+ !StandbyMode ||
+ currentSource != XLOG_FROM_ARCHIVE)
+ return false;
+
+ now = GetCurrentTimestamp();
+
+ /* First time through */
+ if (switched_to_archive_at == 0)
+ {
+ switched_to_archive_at = now;
+ return false;
+ }
+
+ if (TimestampDifferenceExceeds(switched_to_archive_at, now,
+ streaming_replication_retry_interval))
+ return true;
+
+ return false;
+}
/*
* Determine what log level should be used to report a corrupt WAL record
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 70652f0a3f..8c835a37a3 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -3232,6 +3232,18 @@ struct config_int ConfigureNamesInt[] =
NULL, NULL, NULL
},
+ {
+ {"streaming_replication_retry_interval", PGC_SIGHUP, REPLICATION_STANDBY,
+ gettext_noop("Sets the time after which standby attempts to switch WAL "
+ "source from archive to streaming replication."),
+ gettext_noop("0 turns this feature off."),
+ GUC_UNIT_MS
+ },
+ &streaming_replication_retry_interval,
+ 300000, 0, INT_MAX,
+ NULL, NULL, NULL
+ },
+
{
{"wal_segment_size", PGC_INTERNAL, PRESET_OPTIONS,
gettext_noop("Shows the size of write ahead log segments."),
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index e10755972a..1aec929dbc 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -360,6 +360,10 @@
# in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s # time to wait before retrying to
# retrieve WAL after a failed attempt
+#streaming_replication_retry_interval = 5min # time after which standby
+ # attempts to switch WAL source from archive to
+ # streaming replication
+ # in milliseconds; 0 disables
#recovery_min_apply_delay = 0 # minimum delay for applying changes during recovery
# - Subscribers -
diff --git a/src/include/access/xlogrecovery.h b/src/include/access/xlogrecovery.h
index c423464e8b..73c5a86f4c 100644
--- a/src/include/access/xlogrecovery.h
+++ b/src/include/access/xlogrecovery.h
@@ -57,6 +57,7 @@ extern PGDLLIMPORT char *PrimarySlotName;
extern PGDLLIMPORT char *recoveryRestoreCommand;
extern PGDLLIMPORT char *recoveryEndCommand;
extern PGDLLIMPORT char *archiveCleanupCommand;
+extern PGDLLIMPORT int streaming_replication_retry_interval;
/* indirectly set via GUC system */
extern PGDLLIMPORT TransactionId recoveryTargetXid;
diff --git a/src/test/recovery/meson.build b/src/test/recovery/meson.build
index bf087ac2a9..d891199462 100644
--- a/src/test/recovery/meson.build
+++ b/src/test/recovery/meson.build
@@ -46,6 +46,7 @@ tests += {
't/038_save_logical_slots_shutdown.pl',
't/039_end_of_wal.pl',
't/040_standby_failover_slots_sync.pl',
+ 't/041_wal_source_switch.pl',
],
},
}
diff --git a/src/test/recovery/t/041_wal_source_switch.pl b/src/test/recovery/t/041_wal_source_switch.pl
new file mode 100644
index 0000000000..1a9637ec86
--- /dev/null
+++ b/src/test/recovery/t/041_wal_source_switch.pl
@@ -0,0 +1,110 @@
+# Copyright (c) 2024, PostgreSQL Global Development Group
+#
+# Test for WAL source switch feature.
+use strict;
+use warnings FATAL => 'all';
+
+use PostgreSQL::Test::Utils;
+use PostgreSQL::Test::Cluster;
+use Test::More;
+
+# Initialize primary node, setting wal-segsize to 1MB
+my $primary = PostgreSQL::Test::Cluster->new('primary');
+$primary->init(
+ allows_streaming => 1,
+ has_archiving => 1,
+ extra => ['--wal-segsize=1']);
+
+# Ensure checkpoint doesn't come in our way
+$primary->append_conf(
+ 'postgresql.conf', qq(
+min_wal_size = 2MB
+max_wal_size = 1GB
+checkpoint_timeout = 1h
+autovacuum = off
+));
+$primary->start;
+
+$primary->safe_psql('postgres',
+ "SELECT pg_create_physical_replication_slot('standby_slot')");
+
+# Take backup
+my $backup_name = 'my_backup';
+$primary->backup($backup_name);
+
+# Create a streaming standby
+my $standby = PostgreSQL::Test::Cluster->new('standby');
+$standby->init_from_backup(
+ $primary, $backup_name,
+ has_streaming => 1,
+ has_restoring => 1);
+
+my $retry_interval = 1;
+$standby->append_conf(
+ 'postgresql.conf', qq(
+primary_slot_name = 'standby_slot'
+streaming_replication_retry_interval = '${retry_interval}ms'
+log_min_messages = 'debug1'
+));
+$standby->start;
+
+# Wait until standby has replayed enough data
+$primary->wait_for_catchup($standby);
+
+$standby->stop;
+
+# Advance WAL by 5 segments (= 5MB) on primary
+$primary->advance_wal(5);
+
+# Wait for primary to generate requested WAL files
+$primary->poll_query_until('postgres',
+ "SELECT COUNT(*) >= 5 FROM pg_ls_waldir();")
+ or die "Timed out while waiting for primary to generate WAL";
+
+# Wait until generated WAL files have been stored on the archives of the
+# primary. This ensures that the standby created below will be able to restore
+# the WAL files.
+my $primary_archive = $primary->archive_dir;
+$primary->poll_query_until('postgres',
+ "SELECT COUNT(*) >= 5 FROM pg_ls_dir('$primary_archive', false, false) a WHERE a ~ '^[0-9A-F]{24}\$';"
+) or die "Timed out while waiting for archiving of WAL by primary";
+
+# Generate some data on the primary
+$primary->safe_psql('postgres',
+ "CREATE TABLE test_tbl AS SELECT a FROM generate_series(1,5) AS a;");
+
+my $offset = -s $standby->logfile;
+
+# Standby initially fetches WAL from archive after the restart. Since it is
+# asked to retry fetching from primary after retry interval
+# (i.e. streaming_replication_retry_interval), it will do so. To mimic the
+# standby spending some time fetching from archive, we use apply delay
+# (i.e. recovery_min_apply_delay) greater than the retry interval, so that for
+# fetching the next WAL file the standby honours retry interval and fetches it
+# from primary.
+my $apply_delay = $retry_interval * 5;
+$standby->append_conf(
+ 'postgresql.conf', qq(
+recovery_min_apply_delay = '${apply_delay}ms'
+));
+$standby->start;
+
+# Wait until standby has replayed enough data
+$primary->wait_for_catchup($standby);
+
+$standby->wait_for_log(
+ qr/DEBUG: ( [A-Z0-9]+:)? switched WAL source from archive to stream after timeout/,
+ $offset);
+$standby->wait_for_log(
+ qr/LOG: ( [A-Z0-9]+:)? started streaming WAL from primary at .* on timeline .*/,
+ $offset);
+
+# Check that the data from primary is streamed to standby
+my $result =
+ $standby->safe_psql('postgres', "SELECT COUNT(*) FROM test_tbl;");
+is($result, '5', 'data from primary is streamed to standby');
+
+$standby->stop;
+$primary->stop;
+
+done_testing();
--
2.34.1
