Início / dba / Perguntas / 14201
Accepted
wingedrhino
Asked: 2012-03-02 05:47:08 +0800 CST

PostgreSQL Failover - Quais ferramentas devo usar?

  • 772

Aqui está o cenário:

Existem duas máquinas executando o CentOS 6.2 - machine0 e machine1

Ambos possuem o PostgreSQL 9.1 instalado.

Um deles deve estar ativo, como um sistema mestre e através da replicação de fluxo assíncrono da outra máquina, o standby deve copiar as alterações para o banco de dados do sistema mestre.

Assumindo que machine0 é o mestre e machine1 é o standby no início.

Se o mestre (digamos, machine0) falhar (a falha aqui significa que o servidor postgresql trava), o standby deve assumir o controle do mestre e se tornar o novo mestre.

machine1, o novo mestre lida com todas as operações do banco de dados e quando o servidor postgresql em machine0 voltar a ficar online, ele deve se tornar um standby, iniciar a sincronização a partir do ponto em que perdeu o contato com machine1 e copiar todas as alterações no banco de dados e permanecer no modo de espera.

Quando a máquina1 falha, todo o ciclo se repete.

Quando o standby falha e volta a ficar online, ele deve iniciar a leitura do mestre e sincronizar os dados.

Estou confuso sobre quais são as ferramentas que preciso usar para configurar isso, pois entendo que o PostgreSQL não vem com failover por padrão.

Se alguém puder me vincular a tópicos/páginas que descrevam como fazer o que estou tentando, ficarei muito grato.

postgresql replication

1 respostas

  1. Best Answer

    Se você estiver interessado em replicação de banco de dados síncrona e failover, tenho uma sugestão. Você pode pensar em usar duas ferramentas:

    • O DRBD (Disk Replicated Block Device) fornece replicação em nível de disco (síncrona) entre discos em dois servidores diferentes. As alterações de disco são replicadas pela rede. É melhor usar um cabo crossover em eth2 para as NICs usando o netblock 192.168.xx.

    • ucarp permite gerenciamento DBVIP e failover entre dois servidores diferentes.

    Você pode usá-los em conjunto da seguinte maneira:

    • DBServer1 tem IP 10.1.2.30
    • DBServer2 tem IP 10.1.2.40
    • DB VIP é 10.1.2.70

    Configure o ucarp em dois servidores diferentes de forma que cada instância do ucarp se comunique com a outra ao longo de um ID de roteador virtual

    DBServer1 terá

    /usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

    DBServer2 terá

    /usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

    Qual é a razão -b (transmissões) é 3 em um servidor e 4 no outro? Caso ambos os servidores sejam reiniciados, o servidor com o menor -b trará ucarp primeiro. Quanto a -r, essa é a taxa morta. Assim, o DBServer1 será ativado em 15 segundos (3X5) e o DBServer2 será ativado em 20 segundos (4X5).

    Digamos que o DBServer1 trave. O ucarp no DBServer2 verificará por 20 segundos se há um handshake do ucarp no DBServer1. Se nada for detectado, o script vip-up.sh no DBServer2 assumirá o controle do DBVIP.

    OK, tudo isso é apenas para failover e gerenciamento de DBVIP. E o banco de dados PostgreSQL? Surpreendentemente, o PostgreSQL está rodando apenas em um servidor por vez. Quem tem o DBVIP deve ter o DRBD no estado Primário. Isso está relacionado ao script vip-up. Como você faz o script?

    Aqui está o script /usr/local/sbin/vip-down.sh (conceitual)

    #! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm  primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up

    Aqui está o script /usr/local/sbin/vip-down.sh (conceitual)

    #! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l  /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`

    Tudo o que você precisa fazer é configurar pg_hba.conf para garantir que todos os usuários venham via 10.1.2.70

    Essencialmente, o vip-up executa esta sequência

    • Faça com que o DRBD se torne primário
    • Monte a pasta de dados postgres em /dev/drbd0
    • Postgres de inicialização
    • iniciar processo vipmon

    Ao contrário, o vip-down executa esta sequência

    • Postgres de desligamento
    • descontar /dev/drbd0
    • Faça com que o DRBD se torne secundário

    E o vipmon.sh? Você poderia fazer um script para verificar, em um loop indefinido, o estado do postgres (está em execução), verificar o dispositivo DRBD (você ainda pode gravar na pasta de dados de postagens)

    Com esta configuração, você tem postgres no DRBD Primário e uma cópia em nível de disco da pasta de dados postgres no outro DBServer (o Secundário do DRBD). postgres não está rodando no DRBD Secundário.

    Quando um failover acontece, você só precisa de tempo para o ucarp detectar se é seguro montar os dados do postgres, inicializar o postgres e ativar o script vipmon.

    O que há de bom nessa configuração é que, no caso de um failover, o DBServer que se torna o DRBD Primário deve ter uma cópia de 100% no nível do disco do servidor do qual você falhou. Assim, iniciar o postgres deve nivelá-lo em um estado consistente. Os logs de transação (em pg_xlog) devem estar intactos (menos a intermitência devido ao failover)

    Espero que estas sugestões ajudem. Embora eu seja um DBA MySQL, eu uso MySQL e DRBD na empresa de hospedagem do meu empregador regularmente. Eu instalei o MySQL/DRBD da maneira mencionada acima. Eu fiz isso uma vez para um cliente usando PostgreSQL/DRBD. Funciona muito bem. É de código aberto. Você só precisa realizar a devida diligência no aprendizado de DRBD e ucarp. Isso incluiria reconectar o DRBD após um failover, lidar com o cenário de cérebro dividido em que ambos os servidores de banco de dados são primários e coisas assim.

    • 5

relate perguntas