As réplicas do Postgresql ficaram presas na recuperação (o archive_command não será executado em réplicas)

Question

Atualmente, estamos executando um master - > slave, slave, slave, slave configure usando o postgresql 9.2.8 com streaming e o WAL-E / S3 para manipular segmentos wal.

Todas as réplicas devem estar "em recuperação" no momento? Executando SELECT pg_is_in_recovery (); em todos eles retorna verdadeiro, o que é preocupante. Podemos executar consultas sobre eles (assumindo que não demoram mais de 30 segundos).

Estou tentando criar outra réplica de um dos escravos existentes usando o WAL-E, mas atualmente não consigo fazê-lo, pois cada réplica está no modo de recuperação. Não consigo executar o pg_basebackup ou usar os recursos de backup da wal-e nas réplicas.

Amy eu sinto falta de algo claramente óbvio? A única coisa que posso pensar é que tivemos um problema cerca de 2 meses atrás, onde o nosso disco rígido encheu o nosso mestre, e desligou. Conseguimos inicializá-lo, liberar espaço em disco e continuar o streaming / replicação do mestre.

Se eu fosse simplesmente inicializar 3 servidores postgresql e configurá-los em uma cadeia de 3 servidores (mestre - > escravo - > escravo) usando streaming / arquivamento, ele funcionaria corretamente com o WAL-E, como eu fiz . Apenas por algum motivo, não consigo fazer com que nossas réplicas de produção existentes transmitam / arquivem para qualquer outro servidor. Especificamente, o comando archive_ NUNCA é executado em nenhuma das réplicas (porque está preso no modo de recuperação).

Alguém tem alguma sugestão sobre como eu posso depurar / diagnosticar isso? Estou tentando encontrar uma solução sem tempo de inatividade significativo para nosso banco de dados de produção (como sempre posso reimportar o banco de dados para um novo servidor e iniciar a cadeia novamente, mas isso levaria mais de 12 horas).

Veja os detalhes da configuração: link Além do link local_backup_script.sh:

Obrigado!

    

Answer 1

Espero que isso ainda seja uma resposta para sua pergunta, mesmo que eu não tenha resolvido seu problema.

Should all of the replicas currently be "in recovery"? Running SELECT pg_is_in_recovery(); on all of > them returns true, which is concerning. We can run queries on them

Isso é normal. Seu escravo é na recuperação de um tipo, ainda que lento e perpétuo, enquanto ainda mastiga segmentos WAL (ou streaming) de outro servidor.

Just for some reason I'm unable to get our existing production replicas to stream/archive to any other server. Specifically the archive_command is NEVER run on any of the replicas (because it's stuck in recovery mode).

Você está recebendo erros em algum lugar? Lembre-se de que o streaming é iniciado pelos escravos a jusante: em que estado eles estão? Quais dados eles têm? E há algo interessante registrado quando a conexão de streaming é tentada? Lembre-se de que a replicação de streaming integrada do PostgreSQL é independente do sistema de arquivamento (supondo que a máquina de recebimento de dados esteja atualizada); você pode fazer uma conexão em nome do usuário de replicação?

Does anyone have any suggestions on how I can further debug/diagnose this?

Dadas as inconsistências entre a produção e o seu julgamento, parece um erro de configuração escondido em algum lugar, embora eu não saiba nada sobre o WAL-E. Um diff de postgresql.conf , pg_hba.conf (e recovery.conf suponho) seria um início chato, mas bom. Entre seus escravos de produção e trabalhando, escravos de julgamento, isto é.

Você também pode verificar o conteúdo da tabela pg_settings . Se estas são máquinas de produção de longa duração, talvez uma configuração simplesmente não tenha sido aplicada ainda? Sei que você examinou os documentos em replicação em cascata e seus requisitos, mas eu estou ligando-os apenas no caso.