Postgres restaurando replicação, conflito de linha do tempo

Question

Eu tenho um banco de dados postgres (versão 9.4) com replicação de streaming (master, slave configuration). Vamos chamar master db A e slave db B.

O servidor executando A falhou e tivemos que fazer uma transição, onde promovemos B para ser o novo mestre. Até agora está tudo bem e funcionando bem.

Agora eu recuperei o servidor quebrado e quero configurar novamente a replicação para que A possa ser o novo escravo. Então, eu faço um backup de B, coloco no servidor A, configuro o arquivo de recuperação e o inicio. O problema aqui é que ele realmente não funciona mais, pois diz que eles estão em duas linhas de tempo diferentes.

Aqui estão as mensagens de A (novo escravo):

2015-10-30 14:28:04 LOG:  database system was shut down in recovery at 2015-10-30 14:27:28 CET 
2015-10-30 14:28:04 LOG:  entering standby mode 
2015-10-30 14:28:04 LOG:  redo starts at 1A/5802B1A8 
2015-10-30 14:28:04 LOG:  consistent recovery state reached at 1A/581FA248 
2015-10-30 14:28:04 LOG:  record with zero length at 1A/581FA248 
2015-10-30 14:28:04 LOG:  database system is ready to accept read only connections 
2015-10-30 14:28:05 LOG:  started streaming WAL from primary at 1A/58000000 on timeline 2 
2015-10-30 14:28:07 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:07 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0. 
2015-10-30 14:28:12 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:12 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

meu arquivo de recuperação se parece com:

standby_mode = 'on'
primary_conninfo = 'host=serverB port=5432 user=replication-user'
restore_command = 'copy "Z:\pg_xlog\%f" "%p"'
archive_cleanup_command = '"C:\Program Files\PostgreSQL\9.4\bin\pg_archivecleanup" "Z:\pg_xlog" "%r"'
trigger_file = 'Z:\trigger\pgsql.trigger.sekasto021'
recovery_target_timeline = 'latest'

pesquisando eu encontrei quase a mesma pergunta aqui , mas sem respostas. Encontrou uma página de Michael Paquier que descreve o que está acontecendo comigo (embora ele diga que não é um problema da versão 9.3). Ele diz:

FATAL:  timeline 2 of the primary does not match recovery target timeline 1

This can only be solved by copying the WAL segments from the master node or using a WAL archive.

Mas, infelizmente, eu não sei o que ele quer dizer copiando os segmentos wal do mestre usando o arquivo de parede.

Qualquer ajuda / orientação é bem-vinda. Obrigado

Atualização: eu postei esta pergunta no stackoverflow e fui solicitado a colocá-la aqui em vez disso

    

Answer 1

Como mencionado por Craig Ringer, eu fiz um novo backup e verifiquei e depois de configurar o servidor slave funcionou.

Mas enquanto eu estava fazendo tudo isso eu também lembrava que havia um servidor antigo que também era um escravo do antigo mestre db (A) (aquele servidor não deveria estar rodando e é por isso que eu não pensei inicialmente disso). De qualquer forma, depois de derrubar o velho escravo, fazer backup e restaurar novamente, simplesmente funcionou.

Como eu disse, inicialmente pensei que era por causa de um backup ruim, mas acabou sendo uma mensagem de erro sendo produzida por um terceiro servidor (segundo db escravo). Só para provar meu ponto, iniciei o servidor antigo e recebi novamente as mensagens de erro.

2015-10-31 10:26:37 CET ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history
2015-10-31 10:26:37 CET DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

Então, parece que a replicação estava funcionando sozinha, mas essas mensagens de erro feitas por uma segunda replicação estavam me jogando fora.

Novamente, obrigado Craig pela ajuda.

    

Answer 2

Now I have recovered the broken server and want to set up again the replication so A can be the new slave. So, I take a backup from B, put it in server A, set up the recovery file and start it. The problem here is that it doesn't really work any more, as it says they are in two different time lines.

Então você não fez o backup de B corretamente. Parece que os logs estão tentando iniciar a cópia antiga de A como uma réplica de B. Isso não funcionará.

Você deve remover / renomear o diretório de dados antigo de A. Em seguida, use pg_basebackup para fazer um novo backup de B.

(Existem outras maneiras - consulte o manual - mas é o mais simples e fácil de acertar).

O problema com a replicação de streaming após as opções de linha do tempo não está relacionado ao seu problema atual.