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.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
