Subject: Re: Reliable WAL file shipping over unreliable network
To: pgsql-admin@lists.postgresql.org
References: <dd116172-3ddf-ee56-57f3-6e18d49abf8e@shopzeus.com>
 <400AC9CD-1E43-422C-A689-70BDBAFF231E@elevated-dev.com>
 <ee3ae4be-ab24-8443-82c1-95bcd4f86a63@shopzeus.com>
From: =?UTF-8?Q?Nagy_L=c3=a1szl=c3=b3_Zsolt?= <gandalf@shopzeus.com>
Message-ID: <debd4205-e27a-cd9d-9169-6748e65083a2@shopzeus.com>
Date: Wed, 28 Feb 2018 16:46:42 +0100
MIME-Version: 1.0
In-Reply-To: <ee3ae4be-ab24-8443-82c1-95bcd4f86a63@shopzeus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Precedence: bulk


>>> Is there a utility that is widely used for WAL file shipping, and
>>> addresses these problems?
>> rsync
> Should I use rsync with --remove-source-files option? Will that solve
> all problems with unreliable networks?
Another problem with rsync might be that it does not know if a WAL file
on the source side is growing (e.g. being written) and it might start
copy that before it is fully flushed to disk. I see this as a big
problem, but I don't have experience.

My first idea to address this is to execute an archive command something
like this:

test ! -f /pg_wal/%f && cp %p /volume/pg_wal_tmp/%f && mv
/volume/pg_wal_tmp/%f /volume/pg_wal/%f

E.g. move the file into the archive dir only after it has been fully
copied to the destination volume. But then we still have the problem of
partially written files on the slave side.

I can come up with other ideas, but I do not want to reinvent the wheel.
Can somebody please tell me how to deal with partially written WAL files?=


Thanks,

=C2=A0 Laszlo