From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Question about wal files / pg_xlogs |
Date: | 2016-08-04 06:00:05 |
Message-ID: | dc811774-d566-f016-8664-f1b63c8058a9@hogranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 8/3/2016 7:59 PM, Patrick B wrote:
> *postgresql.conf:*
>
> archive_command = 'exec nice -n 19 ionice -c 2 -n 7
> archive_command.bash "%p" slave01 slave02'
>
> *archive_command.bash:*
>
> Basically we use TAR to ship through ssh:
>
> # we use tar over SSH as I don't fully trust scp's exit status.
> The added benefit is that tar preserves all attributes
> # the downside is that it's a little tricky to make the remote
> path relative
> tar -c -O --no-same-owner -C "${WAL_SEGMENT%/*}"
> "${WAL_SEGMENT##*/}" | ssh -p ${NEXT_PORT} -C -o 'BatchMode=yes'
> -o 'CompressionLevel=3' "${USER}(at)${NEXT_HOST}" "exec tar -x
> --no-same-owner --overwrite -C '${WAL_ARCHIVE_PATH}'";
> PS_CONCAT="${PIPESTATUS[*]}";
>
normally, you would ship the archived wal files to a file server via
cp-over-nfs or scp, and have the slaves access them as needed via the
recovery.conf
--
john r pierce, recycling bits in santa cruz
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2016-08-04 06:02:20 | Re: Tunning Server 9.1. |
Previous Message | Periko Support | 2016-08-04 05:13:05 | Tunning Server 9.1. |