Postgres Hot Standby. How or when does the recovery db move recovery.conf to recovery.done?

Поиск
Список
Период
Сортировка
От Dhaval Shah
Тема Postgres Hot Standby. How or when does the recovery db move recovery.conf to recovery.done?
Дата
Msg-id 565237760703202325x1dea150er5734d7a298ec53b7@mail.gmail.com
обсуждение исходный текст
Ответы Re: Postgres Hot Standby. How or when does the recovery db move recovery.conf to recovery.done?
Список pgsql-general
Resending.

I have a "hot" standby. Now, if the primary fails
how do I tell the secondary that come out of recovery mode and move
the recovery.conf to recovery.done and start the db. I mean, what
error code shall I return?

If I return a non-zero error code (1), I get the following result [from
serverlog]:

====
00000001000000000000001B pg_xlog/RECOVERYXLOG
LOG:  restored log file "00000001000000000000001B" from archive
00000001000000000000001C pg_xlog/RECOVERYXLOG
[Main: Triggering Recovery!!!] <---- My script detected that it needs
to trigger recovery...
LOG:  could not open file "pg_xlog/00000001000000000000001C" (log file
0, segment 28): No such file or directory
LOG:  redo done at 0/1B000070
00000001000000000000001B pg_xlog/RECOVERYXLOG
Main: Triggering Recovery!!! <--- My script is called again and the
script says trigger recovery
PANIC:  could not open file "pg_xlog/00000001000000000000001B" (log
file 0, segment 27): No such file or directory
LOG:  startup process (PID 32167) was terminated by signal 6
LOG:  aborting startup due to startup process failure
====

This is what my script is doing:

if ( triggerRecovery() ) {
   print "Main: Triggering Recovery!!! \n";
   return 1;
}

So, the question is, on detecting that the primary is down and to
trigger recovery, what error code shall I return? Or do I have to move
the recovery.conf to recovery.done myself and restart the db?

Regards
Dhaval

В списке pgsql-general по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: select progressive total
Следующее
От: "Anton Melser"
Дата:
Сообщение: Re: "sniffing" postgres queries