Automatizando o failover no PostgreSQL 9.1

18

Como se configura dois servidores idênticos para failover automático no PostgreSQL 9.1.

OS

Centos 5
PostgreSQL 9.1 compilado a partir do código-fonte
A conta de usuário do postgres existe nas duas máquinas e possui uma chave ssh sem senha para conectar-se às duas máquinas.

Minha configuração atual:

Configuração do servidor principal:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

Servidor em espera

postgresql.conf e pg_hba.conf são idênticos ao que está configurado no servidor principal.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

Graças ao hzRoot, agora entendo como mudar o servidor do modo de espera para o mestre.

Usando os comandos a seguir, posso sincronizar o novo escravo com o novo mestre e, em seguida, obter o backup e a execução de replicação.

No novo mestre (10.0.66.2)

  1. su - postgres
  2. toque em trigger.txt em / opt / pgsql91 / data /
  3. recovery.conf torna-se recovery.done
  4. psql -c "; SELECT pg_start_backup ('backup', true)";
  5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
  6. psql -c "; SELECT pg_stop_backup ()";

No novo escravo (10.0.66.1)

  1. crie o recovery.conf: cp recovery.done em recovery.conf
  2. vi recovery.conf altere o endereço IP: primary_conninfo = 'host = 10.0.66.2'
  3. iniciar postgresql

Então, minhas perguntas são agora:

  1. Essa é a maneira correta de trocar de função?
  2. Alguém automatizou esse processo? Em caso afirmativo, o que você fez?
  3. Se a replicação síncrona estiver ativada, notei que o novo servidor mestre não confirmará nenhuma transação porque está aguardando a resposta do escravo. No entanto, não há escravo porque, no outro servidor, o antigo mestre está inoperante. Isso está correto ou preciso desativar temporariamente a replicação síncrona enquanto o novo escravo estiver inativo?
postgresql failover Craig Efrein
fonte
1. sim correto 2. pode ser que seja melhor não automatizar esse processo. 3. então você precisa de 2 escravos e 1 mestre pelo menos. porque como você disse sincronizar. a replicação precisa de pelo menos 2 nós para enviar por push a sincronização. se há apenas um nó mestre, você não será capaz de se comprometer ..
sftsz
as etapas 4, 5 e 6 não são necessárias no novo mestre porque, bem, você está replicando para começar. Segundo, e se o mestre morresse e estivesse offline - você não conseguiria se conectar a ele. As etapas 4,5 e 6 geralmente são executadas em um novo nó escravo que ingressa no pool de replicação.
24413 Eric Eric
@ Eric, como eu brinquei com isso, são necessárias as etapas 4,5,6 para trazer de volta o antigo mestre ao estado de trabalho. Tornar o novo primário em espera imediatamente cria uma nova entrada no WAL, por isso agora é uma entrada à frente do antigo mestre. Iniciar o antigo mestre no modo de espera gerou erros em mim, então eu tive que fazer as etapas 4,5,6 no antigo mestre para sincronizá-lo com o novo mestre (usando pg_basebackup, que pode transmitir todo o xlog do novo mestre - substitui os passos 4,5,6 no postgres> = 9,1 eu acho). Estou correto ou fiz algo errado e isso não deve ser necessário?
Dalibor Filus

Respostas:

8

Confira repmrg :

repmgr é um conjunto de ferramentas de código aberto que ajuda DBAs e administradores de sistemas a gerenciar um cluster de bancos de dados PostgreSQL.

Tirando proveito do recurso Hot Standby introduzido no PostgreSQL 9, o repmgr simplifica bastante o processo de configuração e gerenciamento de banco de dados com requisitos de alta disponibilidade e escalabilidade.

O repmgr simplifica a administração e o gerenciamento diário, aprimora a produtividade e reduz os custos gerais de um cluster PostgreSQL:

  • monitorar o processo de replicação; permitindo que os DBAs emitam alta
  • operações de disponibilidade, como comutações e failovers.

Faz duas coisas:

  1. repmgr: programa de comando que executa tarefas em seu cluster e sai
  2. repmgrd: daemon de gerenciamento e monitoramento que observa o cluster e pode automatizar ações remotas.

Para failover automático, o repmgrd faz o truque e não é um SPOF na sua rede, como o pgPool. No entanto, ainda é importante monitorar todos os daemon e trazê-los de volta após a falha.

A versão 2.0 está prestes a ser lançada, incluindo RPMs.

Frank Heikens
fonte
Olá Frank, obrigado pela sua resposta. Eu não ouvi falar de repmrg e definitivamente tentarei.
Craig Efrein 07/07/2012
Olá novamente Frank, Obrigado pelo repmgr, era exatamente o que eu estava procurando. Finalmente consegui experimentar hoje.
Craig Efrein
4

no seu arquivo recovery.conf, adicione uma linha que diga ao postgres para failover do mestre para o escravo. você deveria adicionar

trigger_file = '/any/file/to/trigger'

quando você cria este arquivo no caminho especificado. nós mudarão. (o arquivo não inclui nada, é apenas um gatilho)

você pode encontrar informações adicionais sobre replicação de streaming

por outro lado, pode ser possível criar automaticamente com alguns truques, mas usar ferramentas de monitoramento e fazer o failover manual será melhor.

sftsz
fonte
Obrigado pela resposta. Pode demorar alguns dias até que eu possa testá-lo, mas com certeza vou voltar para você.
Craig Efrein
Vou dar +1 para a resposta do arquivo trigger_file, que me ajudou a otimizar bastante o processo. Não é a resposta completa que é como automatizar completamente o processo. Outra coisa que notei é que, enquanto o mestre estava inoperante, as transações não foram concluídas porque estava aguardando o reconhecimento do mestre. Isto foi resolvido usando a replicação assíncrona
Craig Efrein
Isso é incrível. Tenho muitas críticas sobre a falta de flexibilidade na implementação de replicação do PostgreSQL, mas essa é uma maneira excelente e simples de lidar com o failover.
Aaron Brown
11
No entanto, ela assume a função de mestre, mesmo quando o próprio mestre ainda está em execução (portanto, você tem dois mestres). Isso não é automatizado pelo postgres.
Dalibor Filus 27/11
0

Alguém já pensou em usar o pgpool-II para isso?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

Estou configurando a replicação para o PostgreSQL. Parece que a parte complicada acontece quando o velho mestre volta.

Pelo que li, o pgpool parece que pode automatizar a maior parte disso. No entanto, não tenho certeza se aproveita os recursos de replicação já presentes no PostgreSQL 9.1.

Paulo SantAnna
fonte
11
O pgPool é um ponto único de falha, você perde tudo quando está em queda.
Frank Heikens
11
Obrigado pela sua resposta. Eu tentei o PGPool II com resultados mistos no CentOS e no Debian e finalmente desisti.
Craig Efrein 07/07/2012
11
Por que não usar o pgpool II com o HAproxy? Com um batimento cardíaco e um ip flutuante ouvindo?
Mikiemorales
Apenas para referência histórica, o pgpool-ii também não é atualmente executado no Windows.
Tommed 26/08/14