Testar a configuração de alta disponibilidade

Observação: O uso do AlloyDB Omni está sujeito ao contrato entre você e o Google que rege as Google Cloud ofertas. Se você não tiver uma Google Cloud conta ou não tiver celebrado um acordo com o Google que governe as Google Cloud ofertas, não prossiga nem faça o download deste software até que o faça. Para criar uma Google Cloud conta, consulte a Google Cloud página inicial.

Garantir a confiabilidade e a qualidade da configuração de alta disponibilidade do Patroni é crucial para manter as operações contínuas do banco de dados e minimizar o tempo de inatividade. Esta página oferece um guia completo para testar seu cluster do Patroni, cobrindo vários cenários de falha, consistência de replicação e mecanismos de failover.

Testar a configuração do Patroni

1. Conecte-se a qualquer uma das suas instâncias do patroni (alloydb-patroni1, alloydb-patroni2 ou alloydb-patroni3) e navegue até a pasta patroni do AlloyDB Omni.

   cd /alloydb/
   

2. Inspecione os registros do Patroni.

   docker compose logs alloydbomni-patroni
   

   As últimas entradas devem refletir informações sobre o nó Patroni. Você vai ver algo semelhante ao seguinte.

   alloydbomni-patroni        | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock
   alloydbomni-patroni        | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock
   alloydbomni-patroni        | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock
   

3. Conecte-se a qualquer instância com Linux que tenha conectividade de rede à sua instância principal do Patroni, alloydb-patroni1, e receba informações sobre a instância. Talvez seja necessário instalar a ferramenta jq executando sudo apt-get install jq -y.

   curl -s http://alloydb-patroni1:8008/patroni | jq .
   

   O resultado será semelhante ao mostrado abaixo.

   {
     "state": "running",
     "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00",
     "role": "master",
     "server_version": 150005,
     "xlog": {
       "location": 83886408
     },
     "timeline": 1,
     "replication": [
       {
         "usename": "alloydbreplica",
         "application_name": "patroni2",
         "client_addr": "10.172.0.40",
         "state": "streaming",
         "sync_state": "async",
         "sync_priority": 0
       },
       {
         "usename": "alloydbreplica",
         "application_name": "patroni3",
         "client_addr": "10.172.0.41",
         "state": "streaming",
         "sync_state": "async",
         "sync_priority": 0
       }
     ],
     "dcs_last_seen": 1715870011,
     "database_system_identifier": "7369600155531440151",
     "patroni": {
       "version": "3.3.0",
       "scope": "my-patroni-cluster",
       "name": "patroni1"
     }
   }
   

Chamar o endpoint da API HTTP do Patroni em um nó do Patroni expõe vários detalhes sobre o estado e a configuração dessa instância específica do PostgreSQL gerenciada pelo Patroni, incluindo informações de estado do cluster, linha do tempo, informações do WAL e verificações de integridade que indicam se os nós e o cluster estão ativos e funcionando corretamente.

Testar a configuração do HAProxy

1. Em uma máquina com um navegador e conectividade de rede para o nó do HAProxy, acesse o seguinte endereço: http://haproxy:7000. Como alternativa, use o endereço IP externo da instância do HAProxy em vez do nome do host.

   Você vai ver algo parecido com a captura de tela a seguir.

   

   Figura 1. Página de status do HAProxy mostrando o status de integridade e a latência dos nós do Patroni.

   No painel do HAProxy, você pode conferir o status de integridade e a latência do nó principal do Patroni, patroni1, e das duas réplicas, patroni2 e patroni3.

2. É possível executar consultas para verificar as estatísticas de replicação no cluster. Em um cliente, como o pgAdmin, conecte-se ao servidor de banco de dados principal pelo HAProxy e execute a consulta a seguir.

   SELECT
         pid, usename, application_name, client_addr, state, sync_state
   FROM
         pg_stat_replication;
   

   Você vai ver algo semelhante ao diagrama abaixo, mostrando que patroni2 e patroni3 estão sendo transmitidos de patroni1.

   

   Figura 2.Saída de pg_stat_replication mostrando o estado de replicação dos nós Patroni.

Testar o failover automático

Nesta seção, no cluster de três nós, simulamos uma interrupção no nó primário interrompendo o contêiner Patroni em execução anexado. É possível interromper o serviço Patroni no primário para simular uma interrupção ou aplicar algumas regras de firewall para interromper a comunicação com esse nó.

1. Na instância principal do Patroni, navegue até a pasta AlloyDB Omni Patroni.

   cd /alloydb/
   

2. Pare o contêiner.

   docker compose down
   

   O resultado será semelhante a este: Isso valida que o contêiner e a rede foram interrompidos.

   [+] Running 2/2
   ✔ Container alloydb-patroni            Removed
   ✔ Network alloydbomni-patroni_default  Removed
   

3. Atualize o painel do HAProxy e veja como o failover acontece.

   

   Figura 3. Painel do HAProxy mostrando o failover do nó principal para o nó de espera.

   A instância patroni3 se tornou a nova principal, e patroni2 é a única réplica restante. A primária anterior, patroni1, está inativa e as verificações de integridade falham.

   O Patroni executa e gerencia o failover por meio de uma combinação de monitoramento, consenso e orquestração automatizada. Assim que o nó principal não renovar o contrato de licença dentro de um tempo limite especificado ou se ele informar uma falha, os outros nós no cluster reconhecerão essa condição pelo sistema de consenso. Os nós restantes se coordenam para selecionar a réplica mais adequada para promover como a nova primária. Depois que uma réplica candidata é selecionada, o Patroni promove esse nó para o principal aplicando as mudanças necessárias, como atualizar a configuração do PostgreSQL e reproduzir todos os registros WAL pendentes. Em seguida, o novo nó primário atualiza o sistema de consenso com o status dele, e as outras réplicas se reconfiguram para seguir a nova instância primária, incluindo a troca da origem de replicação e, possivelmente, a atualização de novas transações. O HAProxy detecta o novo primário e redireciona as conexões de cliente de acordo, garantindo a menor interrupção possível.

4. Em um cliente, como o pgAdmin, conecte-se ao servidor de banco de dados pelo HAProxy e verifique as estatísticas de replicação no cluster após o failover.

   SELECT
         pid, usename, application_name, client_addr, state, sync_state
   FROM
         pg_stat_replication;
   

   Você vai ver algo semelhante ao diagrama abaixo, mostrando que apenas patroni2 está sendo transmitido agora.

   

   Figura 4.Saída de pg_stat_replication mostrando o estado de replicação dos nós do Patroni após o failover.

5. O cluster de três nós pode sobreviver a mais uma falha. Se você interromper o nó principal atual, patroni3, outro failover será realizado.

   

   Figura 5. Painel do HAProxy mostrando o failover do nó principal, patroni3, para o nó reserva, patroni2.

Considerações sobre fallback

O fallback é o processo de restabelecer o antigo nó de origem após um failover. Geralmente, não é recomendável usar o fallback automático em um cluster de banco de dados de alta disponibilidade devido a várias questões críticas, como recuperação incompleta, risco de cenários de divisão de cérebro e atraso de replicação.

No cluster do Patroni, se você mostrar os dois nós em que simulou uma interrupção, eles vão se juntar ao cluster como réplicas de reserva.

Figura 6. Painel do HAProxy mostrando a restauração de patroni1 e patroni3 como nós em espera.

Agora, patroni1 e patroni3 estão sendo replicados a partir da patroni2 principal atual.

Figura 7.Saída de pg_stat_replication mostrando o estado de replicação dos nós do Patroni após o fallback.

Se você quiser usar manualmente o primário inicial, faça isso usando a interface de linha de comando patronictl. Ao optar pelo substituto manual, você garante um processo de recuperação mais confiável, consistente e verificado, mantendo a integridade e a disponibilidade dos sistemas de banco de dados.