PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Gerenciando alta disponibilidade no PostgreSQL – Parte III:Patroni

Em nossas postagens de blog anteriores, discutimos os recursos e o funcionamento do PostgreSQL Automatic Failover (PAF) do Cluster Labs e do Replication Manager (repmgr) do 2ndQuadrant. Na postagem final desta série, revisaremos a última solução, Patroni by Zalando, e compararemos todas as três no final para que você possa determinar qual estrutura de alta disponibilidade é melhor para sua implantação de hospedagem PostgreSQL.

  • Gerenciando a alta disponibilidade no PostgreSQL – Parte I:Failover automático do PostgreSQL
  • Gerenciando a alta disponibilidade no PostgreSQL – Parte II:Gerenciador de replicação

Patronos para PostgreSQL

Patroni surgiu como um fork do Governor, um projeto do Compose. É um conjunto de ferramentas de código aberto, escrito em Python, para gerenciar a alta disponibilidade de clusters PostgreSQL. Em vez de construir seu próprio protocolo de consistência, Patroni aproveita de forma inteligente o modelo de consistência fornecido por um Distributed Configuration Store (DCS). Ele também suporta outras soluções DCS como Zookeeper, etcd, Consul e Kubernetes.

A Patroni garante a configuração de ponta a ponta dos clusters PostgreSQL HA, incluindo replicação de streaming. Ele é compatível com várias maneiras de criar um nó em espera e funciona como um modelo que pode ser personalizado de acordo com suas necessidades.

Essa ferramenta rica em recursos expõe sua funcionalidade por meio de APIs REST e também por meio de um utilitário de linha de comando chamado patronictl. Ele oferece suporte à integração com o HAProxy usando suas APIs de verificação de integridade para lidar com o balanceamento de carga.

O Patroni também oferece suporte à notificação de eventos com a ajuda de retornos de chamada, que são scripts acionados por determinadas ações. Ele permite que os usuários executem qualquer ação de manutenção fornecendo a funcionalidade de pausa/retomada. O recurso de suporte Watchdog torna a estrutura ainda mais robusta.

Como funciona

Inicialmente, os binários PostgreSQL e Patroni precisam ser instalados. Feito isso, você também precisará definir uma configuração HA DCS. Todas as configurações necessárias para inicializar o cluster precisam ser especificadas no arquivo de configuração yaml e o Patroni usará esse arquivo para inicialização. No primeiro nó, Patroni inicializa o banco de dados, obtém o bloqueio de líder do DCS e garante que o nó esteja sendo executado como o mestre.

A próxima etapa é adicionar nós de espera, para os quais o Patroni oferece várias opções. Por padrão, o Patroni usa pg_basebackup para criar o nó de espera e também suporta métodos personalizados como WAL-E, pgBackRest, Barman e outros para a criação do nó de espera. Patroni torna muito simples adicionar um nó de espera e lida com todas as tarefas de inicialização e configuração de sua replicação de streaming.
Gerenciando a alta disponibilidade no #PostgreSQL – Parte III:Patroni vs. PAF vs. repmgrClick To Tweet

Quando a configuração do cluster estiver concluída, o Patroni monitorará ativamente o cluster e garantirá que ele esteja em bom estado. O nó mestre renova o bloqueio líder a cada ttl segundo(s) (padrão:30 segundos). Quando o nó mestre não consegue renovar o bloqueio de líder, o Patroni aciona uma eleição, e o nó que obtiver o bloqueio de líder será eleito como o novo mestre.

Como ele lida com o cenário de cérebro dividido?

Em um sistema distribuído, o consenso desempenha um papel importante na determinação da consistência, e Patroni usa DCS para obter consenso. Somente o nó que detém o bloqueio de líder pode ser o mestre e o bloqueio de líder é obtido via DCS. Se o nó mestre não mantiver o bloqueio de líder, ele será rebaixado imediatamente pelo Patroni para ser executado como espera. Dessa forma, a qualquer momento, pode haver apenas um mestre em execução no sistema.

Existem requisitos de configuração?

  • Patroni precisa do python 2.7 e superior.
  • O DCS e seu módulo python específico devem ser instalados. Para fins de teste, o DCS pode ser instalado nos mesmos nós que executam o PostgreSQL. No entanto, em produção, o DCS deve ser instalado em nós separados.
  • O arquivo de configuração yaml deve estar presente usando estas configurações de alto nível:

    Global/Universal
    Isso inclui configuração como o nome do host (nome) que precisa ser exclusivo para o cluster, o nome do cluster (escopo) e o caminho para armazenar a configuração no DCS (namespace).

    Log
    Configurações de log específicas do Patroni, incluindo nível, formato, file_num, file_size etc.

    Configuração do bootstrap
    Esta é a configuração global para um cluster que será gravado no DCS. Esses parâmetros de configuração podem ser alterados com a ajuda das APIs do Patroni ou diretamente no DCS. A configuração de bootstrap inclui métodos de criação de espera, parâmetros initdb, script de pós-inicialização etc. , modo síncrono etc. Esta seção será gravada em ///config de um determinado armazenamento de configuração após a inicialização do novo cluster.

    PostgreSQL
    Esta seção contém os parâmetros específicos do PostgreSQL, como autenticação, caminhos de diretório para dados, binário e configuração, endereço IP de escuta, etc.

    API REST
    Esta seção inclui a configuração específica do Patroni relacionada às APIs REST, como endereço de escuta, autenticação, SSL etc.

    Consul
    Configurações específicas para Consul DCS.

    Etcd
    Configurações específicas para Etcd DCS.

    Expositor
    Configurações específicas do Expositor DCS.

    Kubernetes
    Configurações específicas do Kubernetes DCS.

    ZooKeeper
    Configurações específicas do ZooKeeper DCS.

    Watchdog
    Configurações específicas do Watchdog.

Prós patronos

  • O Patroni permite a configuração completa do cluster.
  • Suporta APIs REST e integração HAproxy.
  • Suporta notificações de eventos por meio de scripts de retorno de chamada acionados por determinadas ações.
  • Aproveita o DCS para obter consenso.

Contras de patronos

  • Patroni não detectará a configuração incorreta de um standby com um nó desconhecido ou inexistente na configuração de recuperação. O nó será mostrado como escravo mesmo se o modo de espera estiver em execução sem se conectar ao nó de espera mestre/em cascata.
  • O usuário precisa lidar com a configuração, o gerenciamento e a atualização do software DCS.
  • Requer que várias portas estejam abertas para comunicação de componentes:
    • Porta da API REST para Patroni
    • Mínimo de 2 portas para DCS

Cenários de teste de alta disponibilidade

Realizamos alguns testes no gerenciamento de HA do PostgreSQL usando o Patroni. Todos esses testes foram realizados enquanto o aplicativo estava em execução e inserindo dados no banco de dados PostgreSQL. O aplicativo foi escrito usando PostgreSQL Java JDBC Driver, aproveitando o recurso de failover de conexão.

Testes de servidor em espera

Sl. Não Cenário de teste Observação
1 Eliminar o processo PostgreSQL Patroni trouxe o processo PostgreSQL de volta ao estado de execução.
  • Não houve interrupção do aplicativo de gravação.
2 Parar o processo do PostgreSQL Patroni trouxe o processo PostgreSQL de volta ao estado de execução.
  • Não houve interrupção do aplicativo de gravação.
3 Reinicialize o servidor Patroni precisa ser iniciado após a reinicialização, a menos que configurado para não iniciar na reinicialização. Uma vez que o Patroni foi iniciado, ele iniciou o processo do PostgreSQL e configurou a configuração de espera.
  • Não houve interrupção do aplicativo de gravação.
4 Parar o processo Patroni
  • Isso não interrompeu o processo do PostgreSQL.
  • lista patrônica não exibiu este servidor.
  • Não houve interrupção do aplicativo de gravação.

Então, essencialmente, você precisa monitorar a integridade do processo Patroni – caso contrário, isso levará a problemas no futuro.

Testes do servidor mestre/primário

Sl. Não Cenário de teste Observação
1 Eliminar o processo PostgreSQL Patroni trouxe o processo PostgreSQL de volta ao estado de execução. Patroni rodando naquele nó tinha bloqueio primário e assim a eleição não foi acionada.
  • Houve tempo de inatividade no aplicativo de gravação.
2 Parar o processo do PostgreSQL e trazê-lo de volta imediatamente após a expiração da verificação de integridade Patroni trouxe o processo PostgreSQL de volta ao estado de execução. Patroni rodando naquele nó tinha bloqueio primário e assim a eleição não foi acionada.
  • Houve tempo de inatividade no aplicativo de gravação.
3 Reinicialize o servidor Failover aconteceu e um dos servidores em espera foi eleito como o novo mestre após obter o bloqueio. Quando Patroni foi iniciado no antigo mestre, ele trouxe de volta o antigo mestre e executou pg_rewind e começou a seguir o novo mestre.T
  • Houve tempo de inatividade no aplicativo de gravação.
4 Parar/eliminar o processo Patroni
  • Um dos servidores em espera adquiriu o bloqueio DCS e se tornou o mestre ao se promover.
  • O antigo mestre ainda estava em execução e isso levou ao cenário de vários mestres. O aplicativo ainda estava gravando no antigo mestre.
  • Uma vez que o Patroni foi iniciado no antigo mestre, ele rebobinou o antigo mestre (use_pg_rewind foi definido como true) para a nova linha do tempo mestre e lsn e começou a seguir o novo mestre.

Como você pode ver acima, é muito importante monitorar a integridade do processo Patroni no mestre. Não fazer isso pode levar a um cenário multimestre e potencial perda de dados.

Testes de isolamento de rede

Sl. Não Cenário de teste Observação
1 Isole em rede o servidor mestre de outros servidores A comunicação DCS foi bloqueada para o nó mestre.
  • O PostgreSQL foi rebaixado no servidor mestre.
  • Um novo mestre foi eleito na partição majoritária.
  • Houve um tempo de inatividade no aplicativo de gravação.
2 Isole em rede o servidor em espera de outros servidores A comunicação DCS foi bloqueada para o nó em espera.
  • O serviço PostgreSQL estava em execução, porém, o nó não foi considerado para eleições.
  • Não houve interrupção no aplicativo de gravação.

Qual ​​é a melhor estrutura de alta disponibilidade do PostgreSQL?

Patroni é uma ferramenta valiosa para administradores de banco de dados PostgreSQL (DBAs), pois ele executa configuração e monitoramento de ponta a ponta de um cluster PostgreSQL. A flexibilidade de escolha de DCS e criação de standby é uma vantagem para o usuário final, pois ele pode escolher o método com o qual se sente confortável.

APIs REST, integração HaProxy, suporte Watchdog, callbacks e seu gerenciamento rico em recursos fazem do Patroni a melhor solução para gerenciamento de HA PostgreSQL.

Teste do PostgreSQL HA Framework:PAF vs. repmgr vs. Patroni

Incluída abaixo está uma tabela abrangente detalhando os resultados de todos os testes que realizamos em todos os três frameworks – PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) e Patroni.

Testes de servidor em espera

Cenário de teste PostgreSQL Automatic Failover (PAF) Gerenciador de replicação (repmgr) Patroni
Eliminar o processo PostgreSQL O Pacemaker trouxe o processo PostgreSQL de volta ao estado de execução.
  • Não houve interrupção do aplicativo de gravação.
 O servidor em espera foi marcado como falhado. A intervenção manual foi necessária para iniciar o processo do PostgreSQL novamente.
  • Não houve interrupção do aplicativo de gravação.
 Patroni trouxe o processo PostgreSQL de volta ao estado de execução.
  • Não houve interrupção do aplicativo de gravação.
Parar o processo do PostgreSQL O Pacemaker trouxe o processo PostgreSQL de volta ao estado de execução.
  • Não houve interrupção do aplicativo de gravação.
 O servidor em espera foi marcado como falhado. A intervenção manual foi necessária para iniciar o processo do PostgreSQL novamente.
  • Não houve interrupção do aplicativo de gravação.
 Patroni trouxe o processo PostgreSQL de volta ao estado de execução.
  • Não houve interrupção do aplicativo de gravação.
Reinicialize o servidor O servidor em espera foi marcado como offline inicialmente. Assim que o servidor foi inicializado após a reinicialização, o PostgreSQL foi iniciado pelo Pacemaker e o servidor foi marcado como online. Se o fencing estivesse habilitado, o nó não teria sido adicionado automaticamente ao cluster.
  • Não houve interrupção do aplicativo de gravação.
 O servidor em espera foi marcado como falhado. Depois que o servidor foi inicializado após a reinicialização, o PostgreSQL foi iniciado manualmente e o servidor foi marcado como em execução.
  • Não houve interrupção do aplicativo de gravação.
 Patroni precisa ser iniciado após a reinicialização, a menos que configurado para não iniciar na reinicialização. Uma vez que o Patroni foi iniciado, ele iniciou o processo do PostgreSQL e configurou a configuração de espera.
  • Não houve interrupção do aplicativo de gravação.
Parar o processo do agente de estrutura Agente:marcapasso
  • O processo do PostgreSQL foi interrompido e marcado como off-line.
  • Não houve interrupção do aplicativo de gravação.
 Agente:repmgrd
  • O servidor em espera não fará parte da situação de failover automatizado.
  • O serviço PostgreSQL foi encontrado em execução.
  • Não houve interrupção do aplicativo de gravação.
 Agente:patroni
  • Isso não interrompeu o processo do PostgreSQL.
  • lista patrônica não exibiu este servidor.
  • Não houve interrupção do aplicativo de gravação.

Testes do servidor mestre/primário

Cenário de teste PostgreSQL Automatic Failover (PAF) Gerenciador de replicação (repmgr) Patroni
Eliminar o processo PostgreSQL O Pacemaker trouxe o processo PostgreSQL de volta ao estado de execução. O primário foi recuperado dentro do tempo limite e, portanto, a eleição não foi acionada.
  • Houve tempo de inatividade no aplicativo de gravação.
 repmgrd iniciou a verificação de integridade da conexão do servidor primário em todos os servidores em espera por um intervalo fixo. Quando todas as tentativas falharam, uma eleição foi acionada em todos os servidores em espera. Como resultado da eleição, o standby que teve o último LSN recebido foi promovido. Os servidores em espera que perderam a eleição aguardarão a notificação do novo nó mestre e a seguirão assim que receberem a notificação. Foi necessária intervenção manual para iniciar o processo postgreSQL novamente.
  • Houve tempo de inatividade no aplicativo de gravação.
 Patroni trouxe o processo PostgreSQL de volta ao estado de execução. Patroni em execução nesse nó tinha bloqueio primário e, portanto, a eleição não foi acionada.
  • Houve tempo de inatividade no aplicativo de gravação.
Parar o processo do PostgreSQL e trazê-lo de volta imediatamente após a expiração da verificação de integridade O Pacemaker trouxe o processo PostgreSQL de volta ao estado de execução. O primário foi recuperado dentro do tempo limite e, portanto, a eleição não foi acionada.
  • Houve tempo de inatividade no aplicativo de gravação.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.
  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.
  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. O servidor em espera mais qualificado foi promovido como o novo mestre. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.
  • There was downtime in the writer application.
 repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.
  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.
  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker
  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd
  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni
  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Testes de isolamento de rede

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.
  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:
  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:
  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 DCS communication was blocked for master node.
  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.
  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.
  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.