Arquivamento do PostgreSQL WAL no servidor secundário

2

Estou usando o PostgreSQL 9.1 com replicação de streaming para failover e WAL para arquivamento.

Se eu usar a diretiva de configuração archive_command no meu servidor em espera, ela sempre falhará (porque os segmentos do WAL que ela está tentando arquivar já estão arquivados pelo mestre), portanto estou usando um archive_command no servidor em espera

O problema é quando meu servidor mestre está inativo e o servidor em espera se torna o novo arquivamento mestre. Existe alguma maneira de saber no script archive_command se o servidor está sendo executado no modo mestre?

Eu posso criar um script archive_command que retorne 0 se o arquivo com o nome do segmento que eu estou tentando arquivar já existir, mas não tenho certeza se esse é o comportamento correto para archive_command .

    
por Selivanov Pavel 16.05.2013 / 13:19

2 respostas

4

Seus instintos estão corretos - mais ou menos.

Escreva um comando de arquivo que determine se o servidor Postgres local é atualmente o mestre (maneira fácil: Conecte-se e faça SELECT pg_is_in_recovery(); - Se for verdade, você está em um escravo).

Se você detectar que está no servidor mestre, arquive os segmentos normalmente.
Se você detectar que está em um servidor escravo, não faça nada e saia normalmente.

O truque acima funciona porque você não pode se conectar a um mestre que está em recuperação (com falha) - A única vez em que você poderá se conectar a um servidor Postgres que está no modo de recuperação é quando você se conectou a um escravo com replicação de streaming.
Após o failover, seu escravo será um mestre (e não estará mais no modo de recuperação), portanto, os scripts de arquivamento do WAL poderão fazer o que quiserem.

    
por 16.05.2013 / 17:55
0

Tudo está OK: o PostgreSQL no servidor stanby está sendo executado no modo de recuperação, portanto as operações do WAL estão desativadas.

    
por 16.05.2013 / 15:48

Tags