A definição de failback de acordo com os documentos da IBM é “o processo de retornar a produção ao seu local original após um desastre ou um período de manutenção programado”.
Pela minha leitura das postagens da comunidade postgresql, colocar um servidor primário antigo online novamente após o failover como um modo de espera que segue o novo primário também pode ser considerado failover.
Isso pode ocorrer porque é amplamente aceito que ter servidores de banco de dados idênticos é uma prática recomendada. No entanto, esta opção não está disponível para mim.
Tenho 2 servidores: Costanza e Kramer. Costanza é um servidor de alto desempenho. Kramer não.
Aqui está o cenário que estou tentando otimizar, passo a passo:
- Costanza está em modo de falha irrecuperável (típico)
- Kramer é promovido a primário
- Costanza está disponível novamente e o PGDATA está intacto
- Sincronize Costanza e Kramer de forma que nenhum dado gravado em Kramer seja perdido
- Promover Costanza de volta ao status primário
- Estabeleça Kramer como reserva
Estou focado nas etapas 4 e 5.
Ao executar o pg_rewind para reproduzir arquivos WAL, parece que "as modificações que ocorreram no servidor de origem após o último ponto de verificação comum são ignoradas - elas serão recuperadas de qualquer maneira quando o servidor de destino se tornar um modo de espera do servidor de origem". - veja esta pergunta SO
Deduzo disso que simplesmente executar pg_rewind não sincronizará Costanza e Kramer (etapa 4) porque as gravações em Kramer podem ter ocorrido após o último ponto de verificação comum. Isso também é o que observamos ao perfurar failbacks.
Minha solução para a etapa 4 é:
4a. Execute pg_rewind para sincronizar cronogramas divergentes
4b. Estabeleça o Costanza como um standby do Kramer e permita que ele acompanhe o atraso de replicação (assumindo que existam pontos de verificação pós-WALs)
Então
- Desligue Kramer e promova Costanza para primário (novamente causando divergência na linha do tempo)
6a. Execute pg_rewind com Kramer como alvo
6b. Estabeleça Kramer como um standby do Costanza e permita que ele acompanhe o atraso de replicação (novamente, assumindo que existam pontos de verificação pós-WALs)
Este é um cenário pouco frequente. Mas não sei quais modos de falha encontrarei e se o PGDATA estará intacto ou não.
Este é um banco de dados muito grande e quero evitar mover dados por meio de backup de base sempre que possível.
Essa abordagem parece ineficiente para mim porque devo executar o pg_rewind duas vezes e tenho que estabelecer o Costanza como um modo de espera apenas para aplicar as modificações que ocorreram no ponto de verificação pós-comum de Kramer.
Devo minimizar a perda de dados e esta solução parece fazer isso com transferência mínima de dados.
(Um aparte: devo me preocupar com a criação adicional da linha do tempo? Isso parece inevitável, assim como ocorre na promoção de um banco de dados para primário)
Existe alguma maneira de aplicar as modificações no posto de controle comum de Kramer para Costanza sem estabelecer Costanza como reserva de Kramer?
Existe um caminho mais curto para um resultado equivalente? Ou existe um caminho que você pode julgar "mais fácil" de seguir em um cenário de falha de banco de dados?
Antes de responder sua pergunta, deixe-me observar que você esqueceu uma etapa muito importante no procedimento de failover: entre as etapas 1 e 2, você deve ter certeza de que o Constanza está inativo. Isso pode parecer trivial, mas se você não fizer isso, pode acontecer que alguns clientes ainda estejam conectados ao banco de dados no Constanza, e você acabe com um cenário de “cérebro dividido”, que é indiscutivelmente pior do que um tempo de inatividade prolongado. .
Além disso, seus passos são bastante precisos, mas mais complicados do que o necessário. Depois de colocar Constanza em modo de espera e deixá-lo alcançar Kramer, você executa um desligamento limpo em Kramer. Isso garante que todas as alterações no Kramer sejam replicadas no Constanza e não haja necessidade de arquivos
pg_rewind. Tudo o que você precisa fazer é garantir queprimary_conninfoKramer aponte para Constanza e criestandby.signalem Kramer.Se você estiver usando slots de replicação, cada failover e alternância também precisará ser criado após a promoção, porque os slots de replicação ainda não foram replicados (a partir do PostgreSQL v16).
Finalmente, acho que é uma má configuração ter Kramer mais fraco que Constanza. Se Kramer não conseguir lidar com a carga, sua configuração de alta disponibilidade não fornecerá alta disponibilidade.