Desculpe, eu quebrei o seu recovery.conf

No PostgreSQL, desde tempos muito antigos, já a versão 8.0, lançada em 2005, um arquivo de configuração especial recovery.conf foi usado para restaurar em um ponto específico no tempo. O mesmo arquivo subseqüentemente começou a ser usado no modo de espera e na replicação de streaming.

No entanto, desde a próxima versão do PostgreSQL 12, o recovery.conf não funcionará mais: eu o quebrei.
Mas porque?

Recovery.conf tinha um recurso: era somente leitura no início do DBMS. E se a recuperação point-in-time, necessária menos de uma vez por ano, ainda puder ser conciliada, a necessidade de reiniciar todo o banco de dados para alterar o endereço do servidor de replicação upstream é um pouco deprimente. Vi várias maneiras de perversões para contornar essa limitação, como usar roteamento L3, esquemas de replicação em cascata (para que nem todas as réplicas, mas pelo menos apenas parte delas, respectivamente) e até mesmo (mesmo que eu não tenha visto isso em produção) andemilho .

Após o próximo reinício agendado das réplicas, apenas devido à necessidade de alterar os parâmetros de replicação, decidi buscá-lo, mas quanto custaria para ensinar o PostgreSQL a reler o primary_conninfo no SIGHUP? Tudo saiu mal. Em princípio, é necessário alterar apenas uma variável no processo de inicialização e, a partir daí, solicitar a reinicialização do WalReceiver - e é isso, a replicação continuará com o novo endereço corretamente. Resta implementar isso corretamente. Algumas semanas depois, terminei o patch com a implementação da releitura de recovery.conf no sinal SIGHUP, enquanto esse patch não interrompeu o comportamento do banco de dados existente.

Então, tendo a coragem, o enviou à lista de discussão para desenvolvedores do PostgreSQL. O que Michael Paquier respondeu rapidamente:

Antes de tornar alguns deles recarregáveis, vamos trocá-los primeiro por GUCs e não reinventar o manuseio de parâmetros SIGHUP como o seu patch.

Opa, aconteceu que eu fiz a pergunta errada ao mecanismo de pesquisa. A questão não era reler o recovery.conf, mas a conversão de parâmetros de um recovery.conf separado para a infraestrutura GUC (configuração grandiosa unificada) usada para todos os outros parâmetros do DBMS. Ou seja, definitivamente não, não precisamos de um patch, não queremos isso. Vamos primeiro transferir todas essas configurações do recovery.conf para nossa infraestrutura de configurações padrão.

Nesta notícia sombria, eu queimei e pensei: “Mas vamos nos transferir!”. Li as discussões arquivadas na consulta de pesquisa correta, abri a última discussão encontrada sobre as configurações de transferência (o link foi gentilmente fornecido por Michael Paquier em sua resposta, pela qual agradeço separadamente e pela resposta rápida). Naquela época, em maio de 2018, o patch foi abandonado por mais de um ano. Então, aqui começamos. Ou é mais correto dizer "continuar"? De acordo com o plano de entretenimento:

1. leia e liste as alterações na versão publicada mais recente do patch
2. analisar as alterações no patch e transferir o necessário para a versão atual da base de código
3. corrija todas as referências ao recovery.conf e seus parâmetros na documentação
4. testes de reparo
5. envie um novo patch para a lista de discussão
6. obtenha algum feedback
7. corrigir algo de acordo com os desejos e retornar ao parágrafo 5
8. receber uma recusa em aceitar o patch novamente (em um ano e meio)

Parece um plano de ação? Bem, aqui vamos nós!

Por quanto tempo, brevemente, cheguei ao ponto cinco e, em 21 de junho de 2018, publiquei uma nova versão do patch em um novo tópico de discussão . Depois, três meses no silêncio opressivo do silêncio arrepiante do peixe Baskervilles. No final de setembro, Peter Eisentraut, um dos desenvolvedores do Core com o direito de se comprometer, de repente mostrou interesse no patch. Após várias iterações de correções, enquanto eu passava alguns dias em silêncio para passear e ver os pontos turísticos, uma carta desanimadora de Peter Eisentraut chega:

Examinei o patch e fiz vários pequenos refinamentos. Também atualizei a documentação mais amplamente. O patch anexado é aceitável para mim.

Ou seja, Peter Eisentraut corrigiu mais algumas coisinhas a seu critério, atualizou a documentação, queimou toda a seção recovery-config.sgml e acredita que, dessa forma, o patch já pode ser aceito. Ah, e eu pensei que isso aconteceria apenas para o postgresql 13, mesmo que tenha tanta sorte que o patch geralmente atinja um estado de prontidão para confirmação.

E alguns dias depois, em 25 de novembro deste 2018, Peter Eisentraut realmente aceita esse patch :

As configurações de recovery.conf agora estão definidas no postgresql.conf (ou em outras fontes GUC). Atualmente, todas as configurações afetadas são PGC_POSTMASTER; isso pode ser refinado no futuro caso a caso.
A recuperação agora é iniciada por um arquivo recovery.signal. O modo de espera é iniciado por um arquivo standby.signal. A configuração standby_mode desapareceu. Se um arquivo recovery.conf for encontrado, um erro será emitido.
A configuração trigger_file foi renomeada para promover_trigger_file como parte da movimentação.
O capítulo da documentação "Configuração de recuperação" foi integrado à "Configuração do servidor".
pg_basebackup -R agora anexa configurações ao postgresql.auto.conf e cria um arquivo standby.signal.
Autor: Fujii Masao <masao (ponto) fujii (at) gmail (ponto) com>
Autor: Simon Riggs <simon (at) 2ndquadrant (dot) com>
Autor: Abhijit Menon-Sen <ams (at) 2ndquadrant (dot) com>
Autor: Sergei Kornilov <sk (at) zsrv (ponto) org>

Duas semanas se passaram e esse commit não foi revertido. Incrível E parece que eles nem vão. Isso é incrível. Não se sabe se a comunidade decidirá mudar o comportamento novamente em qualquer direção, principalmente porque ainda resta um pouco de tempo antes do congelamento do recurso do postgresql 12 em abril. Mas parece que não teremos mais recovery.conf.

Então, o que mudou

Em primeiro lugar, o DBMS se recusará a iniciar se encontrar um arquivo recovery.conf - isso foi feito especificamente para que o usuário, usando uma das muitas instruções antigas, não se surpreendesse por que o banco de dados ignora a configuração desse arquivo.

A antiga configuração standby_mode desapareceu. Agora, assim como o próprio fato da existência de recovery.conf para ativar o modo de recuperação, é substituído por dois arquivos (com qualquer conteúdo, geralmente vazio):

• $ PGDATA / recovery.signal - sucessor ideológico standby_mode = off, a restauração do arquivo será executada no ponto especificado nas configurações;
• $ PGDATA / standby.signal - respectivamente, standby_mode = ativado. Veremos esse arquivo em todas as réplicas.

Se o processo de inicialização do banco de dados encontrou os dois arquivos, consideramos que estamos no modo de espera.

Se, para maior clareza, reduzir o parâmetro muda para uma placa:

recovery.conf antigo	PostgreSQL 12+ postgresql.conf
primary_conninfo	primary_conninfo
primary_slot_name	primary_slot_name
trigger_file	promotion_trigger_file
recovery_min_apply_delay	recovery_min_apply_delay
recovery_target	recovery_target
recovery_target_name	recovery_target_name
recovery_target_time	recovery_target_time
recovery_target_xid	recovery_target_xid
recovery_target_lsn	recovery_target_lsn
recovery_target_inclusive	recovery_target_inclusive
recovery_target_timeline	recovery_target_timeline
recovery_target_action	recovery_target_action
restore_command	restore_command
archive_cleanup_command	archive_cleanup_command
recovery_end_command	recovery_end_command

Você pode ver que um pouco menos que nada foi alterado. No momento (com a única exceção do prefixo promotion_ para o arquivo promotion_trigger_file), todos os novos parâmetros são nomeados exatamente como os antigos e recebem os mesmos valores possíveis. Embora, de fato, ainda haja uma alteração nas configurações do destino de recuperação. Não sei se alguém usou isso antes, mas foi um comportamento documentado e foi possível especificar vários recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time ou recovery_target_xid ao mesmo tempo. Por exemplo

recovery_target_lsn = '1/1D9FEA00' recovery_target_xid = '5238954' 

A última linha do recovery.conf foi realmente usada para recuperação. Isso não é mais possível, a meta de recuperação deve ser indicada por no máximo uma. No entanto, devido à lógica da infraestrutura GUC, você ainda pode especificar o parâmetro com o mesmo nome várias vezes:

 recovery_target_lsn = '1/1D9FEA00' recovery_target_lsn = '1/16AC7D0' 

Isso é aceitável, seremos restaurados para o valor das configurações especificadas por último.

E, em geral, é tudo o que precisa ser dito sobre as mudanças visíveis fora do PostgreSQL. pg_basebackup -R (--write-recovery-conf) permaneceu em seu lugar e faz o que se destina, somente agora adicionará parâmetros ao postgresql.auto.conf em vez de recovery.conf e cria um arquivo standby.signal

Infelizmente, quando digo que essas são todas as mudanças atualmente visíveis, é exatamente isso que quero dizer. Todos os novos parâmetros ainda estão definidos como PGC_POSTMASTER, ou seja, eles só podem ser alterados quando o PostgreSQL for iniciado. Como já mencionado, esse era um requisito da comunidade de desenvolvedores: primeiro, transfira todas as configurações e só então veja se elas podem ser alteradas no banco de dados em execução. Então agora o PostgreSQL está em um estágio maravilhoso de desenvolvimento, quando o comportamento antigo já foi quebrado e as mudanças para melhor ainda não foram trazidas.

Já publiquei um patch que permitirá alterar primary_conninfo e primary_slot_name em tempo real. Vamos ver o que acontece.

Desculpe, eu quebrei o seu recovery.conf

UPD 7 abril 2019

No último dia antes do recurso de congelamento versão 12, você pode resumir. A alteração das configurações de replicação não foi incluída na versão. Claro, essa também é uma história curiosa. Era uma vez, o patch de Simon Riggs que tomei como base já continha edições para reiniciar o receptor de walkers ao alterar as configurações de conexão. Eu os selecionei em um patch separado, complementando com documentação e testes. E após 6 atualizações de patches e alguns meses de discussão, o fato óbvio aparece: se você reiniciar o walreceiver, o banco de dados tentará mudar para restaurar arquivos do comando restore_command. Um comportamento bastante simples da máquina de estado, acionado pelo desligamento do receptor de walter por qualquer motivo. Mas isso acaba sendo "algo que não queremos". Bem, antes era impossível dizer? Ok, refiz de alguma forma, mas o calendário já tinha o commitfest final para a versão 12 e ninguém olhou aqui. Em geral, isso não é algo rápido, os patches do postgreSQL fazem. Mas tenho todo o direito de me incluir na lista de pessoas, graças a quem o REINDEX inacabado mais épico inacabado CONCURRENTEMENTE foi incluído na versão 12!

Vale ressaltar, no final, que várias configurações têm a oportunidade de mudar rapidamente: archive_cleanup_command, promotion_trigger_file, recovery_end_command, recovery_min_apply_delay