Failover do PostgreSQL - Quais ferramentas devo usar?

Aqui está o cenário:

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

Ambos têm o PostgreSQL 9.1 instalado.

Um deles deve estar ativo, como um sistema mestre e, por meio da replicação de streaming assíncrona na outra máquina, o modo de espera deve copiar as alterações no banco de dados do sistema mestre.

Assumindo que machine0 é o mestre e machine1 é o modo de espera no início.

Se o mestre (digamos, machine0) falhar (falha aqui significa que o servidor postgresql trava), a espera 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 na máquina0 voltar a ficar on-line, ele deverá ficar em espera, iniciar a sincronização a partir do ponto em que perdeu o contato com a máquina1 e copiar todas as alterações no banco de dados e permanecer no modo de espera.

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

Quando o modo de espera falha e volta a ficar on-line, ele deve começar a ler no mestre e sincronizar os dados.

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

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

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

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

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

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

• O DBServer1 possui IP 10.1.2.30
• O DBServer2 possui IP 10.1.2.40
• O 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 é o motivo pelo qual -b (transmissões) é 3 em um servidor e 4 no outro? Caso ambos os servidores sejam reiniciados, o servidor com o menor -b trará o ucarp primeiro. Quanto a -r, essa é a proporção de mortos. Assim, o DBServer1 será exibido em 15 segundos (3X5) e o DBServer2 será exibido em 20 segundos (4X5).

Digamos que o DBServer1 trava. O ucarp no DBServer2 procurará por 20 segundos 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 gerenciamento de failover e DBVIP. E o banco de dados PostgreSQL? Surpreendentemente, o PostgreSQL está sendo executado apenas em um servidor por vez. Quem tiver o DBVIP deve ter DRBD no estado Primário. Isso está relacionado ao script vip-up. Como você escreve isso?

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 que você precisa fazer é configurar o pg_hba.conf para garantir que todos os usuários acessem a versão 10.1.2.70

Essencialmente, o vip-up executa essa sequência

• O DRBD vai Primário
• Monte a pasta de dados do postgres em / dev / drbd0
• Postgres de inicialização
• iniciar processo vipmon

Por outro lado, vip-down executa esta sequência

• Postgres de desligamento
• unount / dev / drbd0
• DRBD tem secundário

E o vipmon.sh? Você pode criar um script para verificar, em um loop indefinido, o estado dos postgres (em execução), verificar o dispositivo DRBD (você ainda pode gravar na pasta de dados dos posts)

Com essa configuração, você tem o postgres no DRBD Primary e uma cópia no nível do disco da pasta de dados do postgres no outro DBServer (o DRBD Secondary). O postgres não está sendo executado no DRBD Secondary.

Quando ocorre um failover, você só precisa de tempo para o ucarp detectar se é seguro montar os dados do postgres, iniciar 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 Primary deve ter uma cópia no nível de disco de 100% do servidor do qual você falhou. Portanto, iniciar o postgres deve nivelá-lo em um estado consistente. Os logs de transações (em pg_xlog) devem estar intactos (menos a intermitência devido ao failover)

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