Re: Enable WAL archiving even in standby - Mailing list pgsql-hackers

From MauMau
Subject Re: Enable WAL archiving even in standby
Date
Msg-id 0387E3AC1E6D46299D06D6877F728962@maumau
Whole thread Raw
In response to Enable WAL archiving even in standby  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
From: "Fujii Masao" <masao.fujii@gmail.com>
> I'd propose the attached WIP patch which allows us to enable WAL archiving
> even in standby. The patch adds "always" as the valid value of 
> archive_mode.
> If it's set to "always", the archiver is started when the server is in 
> standby
> mode and all the WAL files that walreceiver wrote to the disk are archived 
> by
> using archive_command. Then, even after the server is promoted to master,
> the archiver keeps archiving WAL files. The patch doesn't change the 
> meanings
> of the setting values "on" and "off" of archive_mode.
>
> I think that this feature is useful for the case, e.g., where large 
> database
> needs to be replicated between remote servers. Imagine the situation where
> the replicated database gets corrupted completely in the remote standby.
> How should we address this problematic situation and restart the standby?
>
> One approach is to take a fresh backup from the master and restore it onto
> the standby. But since the database is large and there is long distance
> between two servers, this approach might take a surprisingly long time.
>
> Another approach is to restore the backup which was taken from the standby
> before. But most of many WAL files which the backup needs might exist only
> in the master (because WAL archiving cannot be enabled in the standby) and
> they need to be transfered from the master to the standby via 
> long-distance
> network. So I think that this approach also would take a fairly long time.
> To shorten that time, you may think that archive_command in the master can
> be set so that it transfers WAL files from the master to the standby's
> archival storage. I agree that this setting can accelerate the database 
> restore
> process. But this causes every WAL files to be transfered between remote
> servers twice (one is by streaming replication, another is by 
> archive_command),
> and which is a waste of network bandwidth.

Great.  This is exactly what I hoped for disaster recovery, although I 
haven't looked at the patch yet.


> Back to the patch. If archive_mode is set to "always", archive_command is
> always used to archive WAL files even during recovery. Do we need to 
> separate
> the command into two for master and standby, respectively? We can add
> something like standby_archive_command parameter which is used to archive
> only WAL files walreceiver writes. The other WAL files are archived by
> archive_command. I'm not sure if it's really worth separating the command
> that way. Is there any use case?

I don't see any reason to separate parameters.  I want the spec simple.


> I've not included the update of document in the patch yet. If we agree to
> support this feature, I will do the remaining work.

Could you consider adding a new section for disaster recovery that describes 
concrete parameter settings (e.g. how do we discard old archive WAL files 
after taking a base backup from standby, because backup label file is not 
created?).  Good luck!

Regards
MauMau





pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: New PostgreSQL buildfarm client release 4.14 - bug fix for MSVC
Next
From: Alvaro Herrera
Date:
Subject: Re: WAL format and API changes (9.5)