On 08/03/2016 07:59 PM, Patrick B wrote:
>
>
> Both machines have same timezone?
>
>
> Yes! Shouldn't be showing 2 hours before.. I just checked and both
> server has the same date / timezone
>
>
>
> How fast are you generating WALs?
>
>
>
> Check below please
>
> checkpoint_segments = 64
> checkpoint_timeout = 5min
> checkpoint_completion_target = 0.6
> checkpoint_warning = 30s
> archive_timeout = 1800
> max_wal_senders = 8
> wal_keep_segments = 256
>
>
>
>
> How are you shipping the WALs?
>
>
>
> I use a bash script to ship them. The script hasn't being changed.... So
> it isn't the problem.
>
>
> *postgresql.conf:*
>
> archive_command = 'exec nice -n 19 ionice -c 2 -n 7
> archive_command.bash "%p" slave01 slave02'
Seems to me the settings for nice and ionice above would, on a busy
machine, slow down the transfer. Has there always been a notable time
difference in the transfer or has it gotten worse over time?
>
> *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}@${NEXT_HOST}" "exec tar -x
> --no-same-owner --overwrite -C '${WAL_ARCHIVE_PATH}'";
> PS_CONCAT="${PIPESTATUS[*]}";
>
>
> The script is complex, but as I said, nothing has been changed on it.
--
Adrian Klaver
adrian.klaver@aklaver.com
