Re: streaming replication timeout error
| От | 高健 |
|---|---|
| Тема | Re: streaming replication timeout error |
| Дата | |
| Msg-id | CAL454F1TeTqNsPRNohcxOxZ+mN_K1nELt7R1xProtOTdUPD_ag@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: streaming replication timeout error (Adrian Klaver <adrian.klaver@gmail.com>) |
| Ответы |
Re: streaming replication timeout error
(Adrian Klaver <adrian.klaver@gmail.com>)
|
| Список | pgsql-general |
Hello:
Thanks for replying.
The recovery.conf file on standby(DB2) is like that:
standby_mode = 'on'
primary_conninfo = 'host=DB1 port=5432 application_name=testpg user=postgres connect_timeout=10 keepalives_idle=5 keepalives_interval=1'
recovery_target_timeline = 'latest'
restore_command = 'scp -o "ConnectTimeout 5" -i /opt/PostgresPlus/9.2AS/.ssh/id_edb DB1:/opt/PostgresPlus/9.2AS/data/arch/%f %p'
I am not familiar with the scp command, I think that here scp is used to copy archive wal log files from primary to standby...
Maybe the ConnectionTimeout is too small, And sometimes when network is not very well,
the restore_command will fail and return FATAL error?
In fact I am a little confused about restore_command, we are using streaming replication, but why restore_command is still needed to copy archive wal log, isn't it the old warm standby (file shipping)?
Best Regards
jian gao
2013/10/9 Adrian Klaver <adrian.klaver@gmail.com>
On 10/08/2013 07:58 PM, 高健 wrote:Hello:
My customer encountered some connection timeout, while using one
primary-one standby streaming replication.
The original log is japanese, because there are no error-code like
oracle's ora-xxx,
I tried to translate the japanese information into English, But that
might be not correct English for PG.
The most important part is:
2013-09-22 09:52:47 JST[28297][51d1fbcb.6e89-2][0][XX000]FATAL: Could
not receive data from WAL stream: could not receive data from server:
connection timeout
scp: /opt/PostgresPlus/9.2AS/data/arch/000000AC000001F10000004A: No such
file or directory
I was asked about:
In what occasion will the above fatal error occur?
I looked into the postgresql.conf file for the primary and standby server.
And made some experiences.
I found:
Senario I:
If the wal file wanted is removed manually：
Both in primary and standby, log will be like this:
FATAL: could not receive data from WAL stream: FATAL: requested WAL
segment 000000010000000000000011 has already been removedBut I haven't found a good explanation fitting the logs' FATAL error.
Can anybody give me some info?
Would seem to me the interesting part is:Are using scp to move WAL files to an archive directory?
scp: /opt/PostgresPlus/9.2AS/data/arch/000000AC000001F10000004A: No such file or directory
If so, it seems scp is having issues, either network interruption or the file is disappearing under it.--
Thanks in advance
jian gao
Adrian Klaver
adrian.klaver@gmail.com
В списке pgsql-general по дате отправления: