Postgresql 9.3 Envio de log em uma espera a quente

Question

Minha configuração

Acabei de configurar a replicação de streaming no postgres pela primeira vez (9.3.5) e, embora o fluxo esteja funcionando conforme o esperado, estou com dificuldades para fazer com que o meu comando execute o archive_command para que eu possa armazenar todos dos arquivos de log.

Mestre postgres.conf:

wal_level = hot_standby
checkpoint_segments = 8
max_wal_senders = 4
wal_keep_segments = 8

Em espera postgres.conf:

wal_level = hot_standby
checkpoint_segments = 8
archive_mode = on
archive_command = 'test ! -f /backup/postgres_archive/constant/%f && cp %p /backup/postgres_archive/constant/%f'
max_wal_senders = 3
wal_keep_segments = 8
hot_standby = on

Em espera recovery.conf:

standby_mode = 'on'
primary_conninfo = 'host=my-host.example.com port=5432 user=replicator password=my_password sslmode=require'
restore_command = 'cp /backup/postgres_archive/constant/%f %p'
trigger_file = '/tmp/postgresql.trigger'

As permissões da pasta na qual estou tentando gravar estão corretas e o archive_command funciona bem quando eu a executo manualmente enquanto o usuário postgres está sendo executado. Para ter certeza, tentei alterar o comando de arquivamento para um simples toque (novamente, testado como o usuário postgres), mas não fez nenhuma diferença.

Coisas que estão funcionando

Meu banco de dados ainda está em sua infância relativa, então não há muita carga nele. Para este fim, estou apenas simulando isso, escrevendo dados aleatórios em uma tabela de teste. Depois que eu me comprometo com o mestre, posso ver as mudanças aparecendo imediatamente no modo de espera, então estou feliz com isso.

Uma coisa que eu não entendo é que os arquivos WAL são o standby e o master são um pouco diferentes, mas parece que um ou outro já forneceu uma WAL que ainda não começou a ser escrita (o que não é do outro). Isso é normal?

Se eu faço select pg_switch_xlog() no master e depois escrevo um pouco mais, tanto o master como o standby parecem mudar e começar a escrever no próximo / mesmo arquivo WAL. Então, isso reflete minha compreensão do que está acontecendo.

Ajuda

Eu tenho algumas perguntas sobre tudo isso. Eu li todas as páginas dos manuais postgres sobre isso, mas não consegui encontrar nada para ajudar no meu caso particular.

Eu tentei encontrar uma maneira de fazer com que o postgres me mostrasse mais informações sobre o que ele poderia estar fazendo / não fazendo nos arquivos de log, mas não trouxe nada de útil. Ao depurar isso, o que devo alterar na configuração para obter o máximo possível de informações úteis nos logs?

Em termos de quando o arquivamento de log seria executado, eu acho que como o mestre está controlando qual arquivo WAL está ativo, ele é efetivamente o acionador para quando o envio de log deve ser executado no modo de espera. Isso está correto?

A replicação de streaming parece funcionar como eu esperava, mas tentar fazer com que o envio de logs em execução no modo de espera não pareça ser tentado. O que estou fazendo errado?

    

Answer 1

Eu também me deparei com esse problema. A chave aqui é realmente o archive_cleanup_command no "recovery.conf" no standby. A espera executará o comando archive_cleanup_command quando terminar o processamento de um segmento WAL a partir do primário, portanto, nesse ponto, você sabe que pode fazer backup desse segmento do WAL e de todos os segmentos anteriores. No meu "recovery.conf" eu tenho:

archive_cleanup_command = '/var/lib/postgresql/wal_backup_mirror.sh "%r"'

O conteúdo desse script é (versão simplificada):

CURRENT_WAL_FILE="$1"
for WAL_FILE in $(find /pg_logs/main -maxdepth 1 -type f | sort | awk "\
archive_cleanup_command = '/var/lib/postgresql/wal_backup_mirror.sh "%r"'
 <= \"/pg_logs/main/${CURRENT_WAL_FILE}\""); do
  WAL_NAME=$(basename "$WAL_FILE")
  gzip -c "$WAL_FILE" > "/backups/wal/${WAL_NAME}.gz"
  #now upload the just created .gz to S3 or some other offsite storage

  rm -f "${WAL_FILE}"
done

Observe que excluo o segmento WAL depois de fazer backup dele para manter meu diretório de log limpo no modo de espera, mas a única advertência é ter cuidado com uma configuração de replicação em cascata, uma vez que uma espera mais abaixo da cadeia pode ainda precisa desses arquivos.

Uma observação final, lembre-se de que o backup dos segmentos do WAL não é suficiente, isso deve ser feito em combinação com algum tipo de backup completo regular (pg_basebackup). Fazemos backups completos diariamente e depois fazemos backup dos segmentos do WAL conforme necessário ao longo do dia.