Início / dba / Perguntas / 59916
Accepted
Niels Kristian
Asked: 2014-03-01 07:11:48 +0800 CST

O registro de replicação de streaming está me intrigando

  • 772

Eu tenho uma configuração de espera ativa de replicação de streaming, que parece estar funcionando bem. Posso fazer login, executar selects e o resultado parece estar atualizado com o mestre. No entanto, no log do standby, vejo muitos destes:

cp: cannot stat `/mnt/wal_drive/wals/0000000100004BA800000070': No such file or directory
2014-02-28 16:00:37 CET LOG:  record with zero length at 4BA8/70DD79D0
2014-02-28 16:00:37 CET LOG:  started streaming WAL from primary at 4BA8/70000000 on timeline 1
2014-02-28 16:02:59 CET FATAL:  could not receive data from WAL stream: SSL error: sslv3 alert unexpected message

O que cada um deles significa e devo me preocupar com algum deles?

PS. No mestre, vejo alguns deles, que espero estar relacionados à coisa do SSL:

2014-02-28 16:10:33 CET LOG:  SSL renegotiation failure
2014-02-28 16:10:33 CET LOG:  SSL error: unexpected record

Estou executando o postgresql 9.3 no Ubuntu 12.04

EDITAR

Em relação aos logs do WAL tenho a seguinte configuração:

Tanto no meu mestre quanto no meu escravo, montei um armazenamento de rede fstabusando um cifscomando. O diretório é alterado para pertencer ao usuário postgres.

No meu master tenho as seguintes configurações no postgresql.conf:

archive_mode = on
archive_command = 'rsync -a %p /mnt/wal_drive/wals/%f </dev/null'

No slave tenho hot_standby = one o seguinte recovery.conf:

standby_mode = 'on'
primary_conninfo = 'host=localhost port=5433 user=replicator password=some_pass'
trigger_file = '/tmp/pgsql.trigger'
restore_command = 'cp -f /mnt/wal_drive/wals/%f %p </dev/null'
archive_cleanup_command = '/usr/lib/postgresql/9.3/bin/pg_archivecleanup /mnt/wal_drive/wals/ %r'

Eu tenho uma porta de encaminhamento ssh-tunnel 5433 do escravo para a porta 5432 no mestre, portanto, conectar-se em localhost:5433 é na verdade o banco de dados mestre.

postgresql replication

2 respostas

  1. Best Answer

    Você parece ter dois problemas separados com a renegociação do OpenSSL.

    Primeiro - não, eu estava errado, veja a resposta de Daniel .

    Em segundo lugar, você está sendo mordido por um problema de OpenSSL com renegociações. Procurar a mensagem de erro teria dito isso a você. Conforme observado nesse relatório de bug:

    A solução alternativa é definir 'ssl_renegotiation_limit=0'em postgresql.conf

    que pede ao PostgreSQL para dizer ao OpenSSL para parar de tentar renegociações, já que essa versão do OpenSSL quebrou o suporte à renegociação.

    • 6

  2. Esta mensagem:

    cp: não é possível stat `/mnt/wal_drive/wals/0000000100004BA800000070': Arquivo ou diretório inexistente

    é apenas a saída ou restore_commandquando um arquivo ainda não existente é solicitado. Isso é normal e documentado em Configurações de recuperação de arquivo :

    comando_restaurar (string)
    ...

    É importante que o comando retorne um status de saída zero somente se for bem-sucedido. O comando será solicitado para nomes de arquivos que não estão presentes no arquivo; ele deve retornar diferente de zero quando solicitado.

    Para evitar essa mensagem, você pode combinar cpcom test -e /path/to/file && ...verificar silenciosamente a existência do arquivo no restore_commandou criar um script mais elaborado.

    Quanto a esta outra mensagem:

    LOG: registro com comprimento zero em 4BA8/70DD79D0

    é inofensivo na inicialização do servidor. Isso provavelmente significa que você copiou o pg_xlog de um live master, de modo que o arquivo WAL mais recente está inacabado. Se o WAL estivesse em condição irreparável, o servidor não iniciaria.

    O único problema real é a questão da renegociação de SSL, mas já foi respondida .

    • 5

relate perguntas