O failover do pool PG leva a dois mestres independentes com falha de rede

Question

Eu tenho dois servidores configurados com o PG Pool para criar uma configuração de HA para um webapp.

O PGPool e o postgres são executados em ambos os servidores, usando a replicação de streaming do servidor 1 para o servidor 2. A webapp em cada máquina se conecta ao PgPool, que envia a solicitação ao mestre atual. Ele é configurado para failover automático caso uma conexão de banco de dados seja interrompida, executando um script de failover personalizado para rebaixar o servidor 1 para escravo e promover o servidor 2 para mestre.

O que aconteceu esta manhã é que por 2 minutos a rede caiu, o que significa que nem a instância do PGPool conseguiu se comunicar - então cada PGPool achou que a outra máquina estava inoperante.

Servidor 1 - Continua como mestre, desconectando servidor 2
Servidor 2 - Failover iniciado, desconectando o servidor 1 e tornando-se o mestre

Como a rede estava inativa, o comando de failover não conseguia passar para o servidor 1 para torná-lo escravo e vice-versa. Então, quando a rede voltou dois minutos depois, o que eu tinha era dois servidores que pensavam que eram o mestre.

O PgPool não parece ter um comando de failback automático, que poderia ser usado para forçar o servidor 1 a se tornar o mestre novamente quando a rede se reconectar, que é a única solução real em que consigo pensar.

Minha pergunta é como devo lidar com essa situação? Isso é mesmo a arquitetura correta para essa configuração? Certamente este é um cenário comum, não consigo entender como esse tipo de problema pode ser resolvido.

Editar: Seria aconselhável ter o pgpool rodando sob um ip virtual sob o linux-ha? Isso poderia resolver as coisas, e eu já tenho isso pronto para o IP público - dessa forma apenas uma instância pgpool é acessada por qualquer máquina.

    

Answer 1

Primeiro, acho que o pgpool2 tem um comando de failback, mas isso não ajudaria muito nesse caso. O problema é que o caos resultará se ambas as máquinas acharem que são o mestre. Além do mais, aqui você tinha um caso simples: a rede caiu. E se a rede estiver particionada? Ou seja, ambas as máquinas estão conectadas, mas de alguma forma perdem a conectividade umas com as outras. Nesse caso, ambas as máquinas se tornarão a master e servirão clientes diferentes, e você terá um banco de dados bifurcado. É um caso mais raro, mas você tem certeza de que é tão improvável que esteja preparado para arriscar o caos resultante?

Uma alternativa seria esta:

                                    +- master db
                                    |
                ------ pgpool ------+
                                    |
                                    +- hot standby

Nesse caso, no entanto, você tem um único ponto de falha, pgpool, que você provavelmente não deseja. Eu sei apenas duas maneiras de resolver esse problema. O mais fácil é apenas promover um modo de espera para dominar manualmente, e isso é aplicável à sua arquitetura. Seus aplicativos precisarão ir para o modo somente leitura até a intervenção humana.

A segunda maneira é ter quóruns. Uma arquitetura que pode funcionar é esta:

                +--- pgpool standing by -+    +- master db
                |                        |    |
   failover ip -+--- active pgpool      -+----+- hot standby 1
                |                        |    |
                +--- pgpool standing by -+    +- hot standby 2
                                              |
                                              +- hot standby 3

                                              (as many standby servers as
                                              you want, so that you have
                                              read-only load balancing)

Os três pgpools estão sendo executados em três máquinas diferentes, cada uma com seu próprio endereço IP, mas também fornecem um endereço IP de failover adicional, considerado apenas pela máquina ativa, e é o usado pelos clientes. Se o pgpool ativo falhar, um pgpool em standby assumirá o controle. Isso pode ser feito com heartbeat .

Para promover um hot standby para master, um quorum de pgpools (ou seja, pelo menos dois dos três) deve ser decidido; e eles implementarão a decisão somente após um atraso de, digamos, 10 segundos após a decisão. Além disso, o pgpool ativo não pode continuar a usar o banco de dados mestre existente por mais de 10 segundos sem obter confirmação de pelo menos outro pgpool (isso é para evitar que os dois pgpools de espera percam sua conexão com o pgpool ativo e o master ao mesmo tempo, promove um hot standby para master, mas o pgpool ativo continua a usar o master antigo).

Na verdade, o terceiro pgpool não precisa participar do IP de failover e apenas estar lá para ajudar no quorum. Além disso, não sei se o pgpool tem recursos suficientes para fazer isso. Talvez você precise de outro daemon. Uma arquitetura mais geral é esta:

              +--- active pgpool      -+          +- master db
              |                        |          | 
 failover ip -+                       -+----------+- hot standby 1
              |                        |          | 
              +--- pgpool standing by -+      +---+- hot standby 2
                                              |   | 
                                              |   +- hot standby 3
                monitoring daemon 1 ---+      |
                                       |      |
                monitoring daemon 2 ---+------+
                                       |
                monitoring daemon 3 ---+

Nesse caso, o balanceamento de carga feito por pgpool é separado do monitoramento e da promoção de espera para um mestre. Observe que você pode colocar pgpools, servidores de banco de dados e monitores de daemons na mesma máquina, mas os dois pgpools devem estar em duas máquinas diferentes e os três daemons de monitoramento devem estar em três máquinas diferentes. Note que não sei se existe um daemon de monitoramento pronto para uso com todos os recursos necessários.

Os detalhes podem ser alterados, mas acho que, se você faz uma promoção de espera automática para dominar sem usar um quorum, está pedindo por problemas.

    

Answer 2

Is this even the correct architecture for this setup? Surely this is a common scenario, I can't get my head around how this kind of this could be fixed.

Aviso: Eu não usei o pgpool, embora esteja ciente do que ele faz.

No software de clustering, você geralmente não deseja operações automatizadas que possam violar regras de simultaneidade (por exemplo, algo deve estar on-line em um único local) quando o cluster tiver conhecimento do status de menos da metade dos nós. Isso impede que uma condição de cérebro dividido, como você experimentou. Em um cluster de dois nós, isso significaria que, no caso de perda de interconectividade de rede entre os dois nós, nenhum failover automatizado deveria ocorrer. Um ser humano deve tomar a decisão de realizar o failover, tendo verificado que é a ação correta a ser tomada, dependendo do "outro" nó estar off-line, ou aceitando que pode haver uma perda de transações não replicadas. Eu não sei se isso é algo que você pode configurar no pgpool.

    

Answer 3

Se os seus servidores estiverem na mesma LAN (baixa latência de rede para acessar um ao outro), você pode considerar a execução de pgpool no modo multi-master de replicação. Você terá uma pequena sobrecarga imposta pela necessidade de atualizar dois bancos de dados simultaneamente.

No caso de uma falha no sistema, o pgpool pode continuar fornecendo acesso através do nó ativo. Após a recuperação do sistema, você pode executar a recuperação on-line no pgpool para trazer o outro nó para cima.