Eu tenho algumas instâncias do Postgresql 10 em execução no Windows Server que estão em modo de recuperação contínua. De vez em quando eles param de se recuperar sem dar nenhum erro, como neste arquivo de log de exemplo (no formato CSV, removi alguns dos campos para maior clareza):
2022-08-23 19:42:02.391,"restored log file ""000000010000029F0000001A"" from archive"
2022-08-23 19:42:07.638,"restored log file ""000000010000029F0000001B"" from archive"
2022-08-23 19:42:13.276,"restored log file ""000000010000029F0000001C"" from archive"
2022-08-23 19:42:18.464,"restored log file ""000000010000029F0000001D"" from archive"
2022-08-23 19:42:18.699,"redo done at 29F/1CFFF7F8"
2022-08-23 19:42:18.708,"last completed transaction was at log time 2022-07-20 12:49:38.247406-03"
2022-08-23 19:42:24.304,"restored log file ""000000010000029F0000001C"" from archive"
2022-08-23 19:42:48.625,"selected new timeline ID: 2"
2022-08-23 19:43:13.718,"archive recovery complete"
2022-08-23 19:43:27.746,"database system is ready to accept connections"
Isso acontece mesmo que o próximo arquivo wal a ser restaurado na sequência (000000010000029F0000001D, 000000010000029F0000001E) esteja presente no diretório de archive. O comando de restauração que estou usando é algo assim:
restore_command = '"C:/program files/postgresql/10/bin/pg_standby.exe" -s 2 D:/archive/127 %f %p %r 2>>D:/archive/127/pg_standby.log'
Minha pergunta é: existe alguma maneira de descobrir o que causou a interrupção da recuperação da instância?
Se a recuperação for interrompida e o servidor promover sem que você o instrua explicitamente, você provavelmente está no modo de recuperação de arquivamento em vez de no modo de espera.
Desde o PostgreSQL v12, você ativa o modo de espera criando um arquivo
standby.signalem vez dorecovery.signaldiretório de dados do PostgreSQL.Antes do PostgreSQL v12, você tinha que configurar
standby_mode = onpararecovery.confconseguir a mesma coisa.