From: | Venkata Balaji N <nag1010(at)gmail(dot)com> |
---|---|
To: | Patrick B <patrickbakerbr(at)gmail(dot)com> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Question about wal files / pg_xlogs |
Date: | 2016-08-04 04:08:29 |
Message-ID: | CAEyp7J8Zj4hAF-rKvAaKSzpD5ZiyR7jSXTxgjy7rsS+iRdbytw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> 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'
>
> *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[*]}";
>
>
> The script is complex, but as I said, nothing has been changed on it.
>
Not sure why the script is so complex. Do you see any messages in the
postgresql log file on master ? and on slave ? which indicates the reason
for delayed shipping of WAL archives. Did you notice any network level
issues ?
Regards,
Venkata B N
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Periko Support | 2016-08-04 05:13:05 | Tunning Server 9.1. |
Previous Message | Patrick B | 2016-08-04 02:59:10 | Re: Question about wal files / pg_xlogs |