Re: Reliable WAL file shipping over unreliable network

From: Rui DeSousa <rui(dot)desousa(at)icloud(dot)com>
To: scott ribe <scott_ribe(at)elevated-dev(dot)com>
Cc: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Dianne Skoll <dfs(at)roaringpenguin(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: Reliable WAL file shipping over unreliable network
Date: 2018-03-01 14:21:18
Message-ID: E6AB850C-D05E-405B-8D4E-DE18E128F402@icloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> On Mar 1, 2018, at 12:21 AM, scott ribe <scott_ribe(at)elevated-dev(dot)com> wrote:
>
> The false report of success is not good, but it's not the root problem.

A false success if a problem; especially in this use case as the source WAL file will be deleted by Postgres before it was truly successful. While monitoring is nice to avoid the issue it is not a fix for the issue.

I personally cannot recommend the use of rsync in this application for two reasons.

1. It adds no value; it’s a more complex cp command (no bandwidth saved, etc as archive processes a single file at a time).
2. It lies on success/failure — Period.

I have use “cat” longer than I have used rsync to archive WALs. I can say that I’ve lost zero WAL files using cat; I can not say the same for rsync.

The following code is more reliable than rsync and works with across multiple platforms and filesystems without fail.

STS=3

OUTPUT=$(cat $XLOGFILE | $SSH_CMD "(mkdir -p $ARCH_DIR && cat > $ARCH_DIR/$WALFILE.swap) && mv $ARCH_DIR/$WALFILE.swap $ARCH_DIR/$WALFILE")
if [ $? == 0 ]; then
STS=0
fi

exit $STS

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message MichaelDBA 2018-03-01 16:06:37 Re: Postgresql | Vacuum information
Previous Message Ibrahim Edib Kokdemir 2018-03-01 06:25:30 Re: Separate log for a specfic database