Início / dba / Perguntas / 11094
Accepted
KajMagnus
Asked: 2012-01-22 01:27:22 +0800 CST

Replicação de streaming do PostgreSQL quebrada: número mágico inválido, ID da linha do tempo fora de sequência

  • 772

Por algum motivo, meu escravo PostgreSQL não replica mais as alterações no mestre. Ele estava funcionando antes, por um tempo, mas recentemente notei que o conteúdo do banco de dados do escravo é antigo e há erros nos arquivos de log do escravo, ou seja, " número mágico inválido 0000 " e " ID 1 da linha do tempo fora de sequência (após 2) ".

Você tem alguma ideia de como posso resolver isso? Ou por que isso acontece?

Os detalhes seguem.

Mensagens de erro do arquivo de log : (no escravo, pg_log/postgresql-Sat.log)

LOG:  entering standby mode
LOG:  redo starts at 0/1C78848
LOG:  consistent recovery state reached at 0/1C7FA30
LOG:  database system is ready to accept read only connections
LOG:  invalid magic number 0000 in log file 0, segment 1, offset 14942208
LOG:  streaming replication successfully connected to primary
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
FATAL:  terminating walreceiver process due to administrator command
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
...

Logs de transação: (no escravo -- estranho, arquivo de log 0...2... 1 é de janeiro de 2012 , mas 0...2... 2 é de dezembro de 2011 !?)

-bash-4.1$ tree -D pg_xlog/
pg_xlog/
├── [Dec  6  6:27]  000000010000000000000001
├── [Jan 20 21:33]  000000020000000000000001
├── [Dec 21  5:29]  000000020000000000000002
├── [Dec  6  6:30]  00000002.history
└── [Dec  6  6:30]  archive_status
    └── [Dec  6  6:30]  00000002.history.ready

1 directory, 5 files
-bash-4.1$ cat pg_xlog/00000002.history 
1       000000010000000000000001        no recovery target specified

Logs de transação : (no mestre )

-bash-4.1$ tree -D pg_xlog/
pg_xlog/
├── [Dec  6  6:27]  000000010000000000000001
├── [Jan 21  8:55]  000000020000000000000001
├── [Dec 21  5:31]  000000020000000000000002
├── [Dec  6  6:30]  00000002.history
└── [Dec  6  6:30]  archive_status
    └── [Dec  6  6:30]  00000002.history.ready

-bash-4.1$ cat pg_xlog/00000002.history 
1       000000010000000000000001        no recovery target specified

Arquivos de configuração: (no escravo)

---postgresql.conf---
wal_level = hot_standby
...
hot_standby = on
...

---recovery.conf---
standby_mode = 'on'
primary_conninfo = 'host=dw0azewdbpv11danny user=replicator password=...'
recovery_target_timeline = 'latest'

Por fim, sobre o escravo, ps auxmostra que:

Jan20 0:01 postgres: startup process waiting for 000000020000000000000001

Atualização uma semana depois:

Parece haver um bug de replicação para compilações do PostgreSQL com gcc 4.6.0.
http://archives.postgresql.org/pgsql-general/2011-07/msg00686.php
e
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=45d792f70272ed57b932816562f31c2f79426c2a
No entanto, eu adivinharia que esse bug não afetaria o 9.1?

As versões do PostgreSQL devem ser idênticas no mestre e no escravo, e SELECT version() se parece com isso no mestre e no escravo:

-bash-4.1$ psql
psql (9.1.1)
Type "help" for help.

postgres=# SELECT version();
                                                   version                                                    
--------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6), 64-bit
(1 row)

Talvez eu também deva mencionar que o mestre atual era um escravo, originalmente, e o escravo atual era o mestre, originalmente. -- Fiz um failover, para testar se funcionou bem.

(Farei essa pergunta nas listas de discussão do Postgres.)

postgresql replication

2 respostas

  1. Best Answer

    Isso não soa como a mesma coisa. A versão do GCC é diferente e sua versão do PostgreSQL é diferente. IIRC era um problema com as otimizações do GCC 4.6 e foi corrigido. Não acredito que isso deva ter afetado sua configuração.

    Mais provavelmente algo mudou que causou isso. Talvez o escravo tenha sido promovido a mestre brevemente e depois rebaixado novamente? Isso criará problemas como esse o tempo todo.

    A questão da linha do tempo me sugere que isso é de fato o que aconteceu. Não importa se você escreve em um banco de dados ou não, apenas concluir a recuperação e a promoção é suficiente para quebrar a linha do tempo.

    • 4

  2. Corri para o mesmo problema, no meu caso houve um erro de digitação/ortografia no arquivo recovery.conf. Verifique também o número da porta, ele deve corresponder à porta de instalação postgres do servidor. Quase demorei dois dias para descobrir.

    Achei que ajudaria alguém.

    • 0

relate perguntas