Re: history file on replica and double switchover

From: David Zhang <david(dot)zhang(at)highgo(dot)ca>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: history file on replica and double switchover
Date: 2020-09-25 04:00:19
Message-ID: df697973-aca7-4e6b-2d9f-871281882904@highgo.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-09-24 5:00 p.m., Fujii Masao wrote:
>
>
> On 2020/09/25 8:15, David Zhang wrote:
>> Hi,
>>
>> My understanding is that the "archiver" won't even start if
>> "archive_mode = on" has been set on a "replica". Therefore, either
>> (XLogArchiveMode == ARCHIVE_MODE_ALWAYS) or (XLogArchiveMode !=
>> ARCHIVE_MODE_OFF) will produce the same result.
>
> Yes, the archiver isn't invoked in the standby when archive_mode=on.
> But, with the original patch, walreceiver creates .ready archive
> status file
> even when archive_mode=on and no archiver is running. This causes
> the history file to be archived after the standby is promoted and
> the archiver is invoked.
>
> With my patch, walreceiver creates .ready archive status for the
> history file
> only when archive_mode=always, like it does for the streamed WAL files.
> This is the difference between those two patches. To prevent the streamed
> timeline history file from being archived, IMO we should use the
> condition
> archive_mode==always in the walreceiver.
+1
>
>
>>
>> Please see how the "archiver" is started in
>> src/backend/postmaster/postmaster.c
>>
>> 5227                 /*
>> 5228                  * Start the archiver if we're responsible for
>> (re-)archiving received
>> 5229                  * files.
>> 5230                  */
>> 5231                 Assert(PgArchPID == 0);
>> 5232                 if (XLogArchivingAlways())
>> 5233                         PgArchPID = pgarch_start();
>>
>> I did run the nice script "double_switchover.sh" using either
>> "always" or "on" on patch v1 and v2. They all generate the same
>> results below. In other words, whether history file
>> (00000003.history) is archived or not depends on "archive_mode"
>> settings.
>>
>> echo "archive_mode = always" >> ${PGDATA_NODE2}/postgresql.auto.conf
>>
>> $ ls -l archive
>> -rw------- 1 david david 16777216 Sep 24 14:40 000000010000000000000002
>> ... ...
>> -rw------- 1 david david 16777216 Sep 24 14:40 00000002000000000000000A
>> -rw------- 1 david david       41 Sep 24 14:40 00000002.history
>> -rw------- 1 david david       83 Sep 24 14:40 00000003.history
>>
>> echo "archive_mode = on" >> ${PGDATA_NODE2}/postgresql.auto.conf
>>
>> $ ls -l archive
>> -rw------- 1 david david 16777216 Sep 24 14:47 000000010000000000000002
>> ... ...
>> -rw------- 1 david david 16777216 Sep 24 14:47 00000002000000000000000A
>> -rw------- 1 david david       41 Sep 24 14:47 00000002.history
>>
>>
>> Personally, I prefer patch v2 since it allies to the statement here,
>> https://www.postgresql.org/docs/13/warm-standby.html#CONTINUOUS-ARCHIVING-IN-STANDBY
>>
>> "If archive_mode is set to on, the archiver is not enabled during
>> recovery or standby mode. If the standby server is promoted, it will
>> start archiving after the promotion, but will not archive any WAL it
>> did not generate itself."
>>
>> By the way, I think the last part of the sentence should be changed
>> to something like below:
>>
>> "but will not archive any WAL, which was not generated by itself."
>
> I'm not sure if this change is an improvement or not. But if we apply
> the patch I proposed, maybe we should mention also history file here.
> For example, "but will not archive any WAL or timeline history files
> that it did not generate itself".
make sense for me
>
> Regards,
>
--
David

Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-09-25 04:21:05 Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Previous Message Greg Nancarrow 2020-09-25 03:40:47 Re: Parallel INSERT (INTO ... SELECT ...)