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

Gerenciando a alta disponibilidade do PostgreSQL – Parte I:Failover automático do PostgreSQL

O gerenciamento de alta disponibilidade (HA) em sua hospedagem PostgreSQL é um tópico muito importante para garantir que seus clusters de implantação de banco de dados mantenham um tempo de atividade excepcional e um forte desempenho operacional para que seus dados estejam sempre disponíveis para seu aplicativo. Em uma postagem anterior do blog, apresentamos a configuração de alta disponibilidade para PostgreSQL usando replicação de streaming e agora mostraremos como gerenciar melhor a alta disponibilidade do lado do cliente.

Existem várias ferramentas disponíveis para gerenciar a alta disponibilidade (HA) de seus clusters de implantação do PostgreSQL usando replicação de streaming. Essas soluções oferecem recursos de failover automático, monitoram a disponibilidade e o status do sistema, replicação, gerenciamento de usuários e outras tarefas administrativas úteis em casos de uso para bancos de dados Postgres. Algumas das soluções de código aberto proeminentes incluem:

  1. Failover automático do PostgreSQL por ClusterLabs

  2. Gerenciador de replicação para clusters PostgreSQL por repmgr (2ndQuadrant)

  3. Patroni por Zalando

Cada ferramenta oferece sua própria maneira de gerenciar os clusters PostgreSQL de alta disponibilidade. Em nossa série de três posts sobre HA para PostgreSQL, compartilharemos uma visão geral, os pré-requisitos e os resultados de trabalho e teste para cada uma dessas três ferramentas. Aqui na Parte 1, vamos nos aprofundar na solução PAF da ClusterLabs.

  • Gerenciando a alta disponibilidade no PostgreSQL – Parte II:Gerenciador de replicação
  • Gerenciando a alta disponibilidade no PostgreSQL – Parte III:Patroni

Como gerenciar alta disponibilidade para seu banco de dados PostgreSQL?

PostgreSQL Automatic Failover (PAF) é uma solução de gerenciamento de alta disponibilidade para PostgreSQL da ClusterLabs. Ele usa a replicação síncrona do Postgres para garantir que nenhum dado seja perdido no momento da operação de failover. Ele faz uso da popular pilha Pacemaker e Corosync padrão do setor. Com os aplicativos Pacemaker e Corosync juntos, você poderá detectar falhas no banco de dados PostgreSQL no sistema e agir de acordo.

O Pacemaker é um serviço capaz de gerenciar muitos recursos e faz isso com a ajuda de seus agentes de recursos. Os agentes de recursos, então, têm a responsabilidade de lidar com um recurso específico, como eles devem se comportar e informar o Pacemaker sobre seus resultados.

Sua implementação do agente de recursos deve estar em conformidade com a especificação Open Cluster Framework (OCF). Esta especificação define o comportamento dos agentes de recursos e a implementação de métodos como parar, iniciar, promover, rebaixar e interagir com o Pacemaker.

PAF é um agente de recursos OCF para Postgres escrito em Perl. Uma vez que seu cluster de banco de dados é construído usando replicação de streaming interno, o PAF é capaz de expor ao Pacemaker o status atual da instância do PostgreSQL em cada um dos nós do banco de dados:mestre, escravo, parado, atualizado, balanceador de carga etc.

Como funciona o failover automático do Postgres

O PAF se comunica com o Pacemaker sobre o status do cluster e monitora o funcionamento do banco de dados PostgreSQL. Em caso de falha, ele informa ao Pacemaker e, se não houver chance de recuperação do mestre atual, ele acionará uma eleição entre um dos servidores de banco de dados em standby atuais. Com o Pacemaker robusto instalado, o Postgres Automatic Failover executará ações de gerenciamento como iniciar, parar, monitorar e fazer failover em todos os nós dos bancos de dados Postgres.

Gerenciando a alta disponibilidade no PostgreSQL - Parte I:Failover automático por ClusterLabsClick To Tweet

Failover automático do PostgreSQL para configuração de alta disponibilidade (HA)

  • O PAF é compatível com o PostgreSQL versão 9.3 e superior.
  • O PAF não é responsável pela criação do PostgreSQL master/standby ou de sua configuração . Você deve criar e configurar a replicação de streaming antes de usar o PAF.
  • O PAF não edita nenhum requisito de configuração ou configuração do PostgreSQL. No entanto, exige que os usuários do banco de dados sigam alguns pré-requisitos como:
    • Slave deve ser configurado como hot standby. Os nós escravos de espera ativa podem ser consultados como bancos de dados somente leitura.
    • Um arquivo de modelo de recuperação (padrão:/recovery.conf.pcmk) deve ser fornecido com os parâmetros abaixo:
      • modo_de espera =ativado
      • recovery_target_timeline ='mais recente'
      • primary_conninfo deve ter o parâmetro application_name definido e configurado para o nome do nó local como no Pacemaker.
  • PAF expõe vários parâmetros relacionados ao gerenciamento de um recurso Postgres. Isso pode ser configurado para atender às necessidades de cada um. Abaixo estão os parâmetros:
    • binário: localização dos binários do PostgreSQL (padrão:/usr/bin)
    • pgdata: localização do PGDATA de sua instância (padrão:/var/lib/pgsql/data)
    • diretório de dados: caminho para o diretório definido em data_directory do seu arquivo postgresql.conf
    • pghost: o diretório de soquete ou endereço IP a ser usado para conectar-se à instância local (padrão:/tmp)
    • pgport: a porta para se conectar à instância local (padrão:5432)
    • recovery_template: o modelo local que será copiado como o arquivo PGDATA/recovery.conf. Este arquivo de modelo deve existir em todos os nós (padrão:$PGDATA/recovery.conf.pcmk)
    • start_opts: Argumentos adicionais fornecidos ao processo Postgres na inicialização. Veja “postgres –help” para as opções disponíveis. Útil quando o arquivo postgresql.conf não está no diretório de dados (PGDATA), ex.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
    • user_user: o proprietário do sistema do processo da sua instância (padrão:postgres)
    • lag máximo: atraso máximo permitido em um modo de espera antes de definirmos uma pontuação mestre negativa para ele

Prós de failover automático do Postgres

  • O PAF fornece ao usuário uma configuração prática e gratuita do PostgreSQL.
  • O PAF pode lidar com falhas de nó e acionar eleições quando o mestre ficar inativo.
  • O comportamento do quórum pode ser aplicado no PAF.
  • Ele fornecerá uma solução completa de gerenciamento de bancos de dados de alta disponibilidade (HA) para o recurso, incluindo iniciar, parar, monitorar e lidar com cenários de isolamento de rede.
  • É uma solução distribuída, que permite o gerenciamento de qualquer nó de outro nó.

Contras do Failover Automático do Postgres

  • O PAF não detecta se um nó em espera está configurado incorretamente 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.
  • Requer que uma porta extra (padrão 5405) seja aberta para a comunicação dos componentes Pacemaker e Corosync usando UDP.
  • Não é compatível com configuração baseada em NAT.
  • Não há suporte para pg_rewind.

Alta disponibilidade para cenários de teste do PostgreSQL

Realizamos alguns testes para determinar a capacidade do gerenciamento de alta disponibilidade (ha) do PostgreSQL usando PAF em alguns casos de uso. Todos esses testes foram executados enquanto a aplicação estava rodando e inserindo dados no banco de dados PostgreSQL. O aplicativo foi escrito usando o driver PostgreSQL Java JDBC, 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 O Pacemaker trouxe o processo PostgreSQL de volta ao estado de execução. Não houve interrupção no aplicativo do gravador.
2 Parar o processo do PostgreSQL O Pacemaker trouxe o processo PostgreSQL de volta ao estado de execução. Não houve interrupção no aplicativo do gravador.
3 Reinicialize o servidor O nó do servidor de banco de dados em espera foi marcado como offline inicialmente. Assim que o servidor foi inicializado após a reinicialização, o banco de dados 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 no aplicativo do gravador.
4 Parar o processo do marcapasso Ele também interromperá o processo do PostgreSQL e o nó do servidor será marcado como offline. Não houve interrupção no aplicativo do gravador.

Testes do servidor mestre/primário

Sl. Não Cenário de teste Observação
1 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. O aplicativo de gravação ficou inativo por cerca de 26 segundos.
2 Parar o processo do 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 um tempo de inatividade no aplicativo de gravação por cerca de 26 segundos.
3 Reinicialize o servidor A eleição foi acionada pelo Pacemaker após o tempo limite para o qual o mestre não estava disponível. O servidor em espera mais qualificado foi promovido como o novo mestre. Depois que o mestre antigo era ativado após a reinicialização, ele era adicionado novamente ao cluster de banco de dados como um modo de espera. Se o fencing estivesse habilitado, o nó não teria sido adicionado automaticamente ao cluster. O serviço do aplicativo de gravação ficou inativo por cerca de 26 segundos.
4 Parar o processo do marcapasso Ele também interromperá o processo do PostgreSQL e o servidor será marcado como offline. A eleição será acionada e um novo mestre será eleito. Houve tempo de inatividade no aplicativo do gravador.

Testes de isolamento de rede

Sl. Não Cenário de teste Observação
1 A rede isola o servidor em espera de outros servidores O tráfego Corosync foi bloqueado no servidor em espera. O servidor foi marcado como offline e o serviço PostgreSQL foi desativado devido à política de quorum. Não houve interrupção no aplicativo de gravação.
2 A rede isola o servidor mestre de outros servidores (cenário de cérebro dividido) O tráfego Corosync foi bloqueado no servidor mestre. O serviço PostgreSQL foi desativado e o servidor mestre foi marcado como offline devido à política de quorum. Um novo mestre foi eleito na partição majoritária. Houve um tempo de inatividade no aplicativo de gravação.

Testes diversos

Sl. Não Cenário de teste Observação
1 Degrade o cluster desligando todos os servidores em espera. Quando todos os servidores em espera foram desativados, o serviço PostgreSQL no mestre foi interrompido devido à política de quorum. Após este teste, quando todos os servidores em espera foram acionados, um novo mestre foi eleito. Houve um tempo de inatividade no aplicativo de gravação.
2 Desligue aleatoriamente todos os servidores um após o outro, começando pelo mestre, e traga todos de volta ao mesmo tempo Todos os servidores surgiram e se juntaram ao cluster. Novo mestre foi eleito. Houve um tempo de inatividade no aplicativo de gravação.

O PAF é a solução para alta disponibilidade do PostgreSQL?

O Failover Automático do Postgres oferece várias vantagens ao lidar com a alta disponibilidade (HA) do PostgreSQL em muitos casos de uso. O PAF usa o failover de endereço IP em vez de reinicializar o modo de espera para se conectar ao novo mestre durante um evento de failover. Isso se mostra vantajoso em cenários em que o usuário não deseja reiniciar os nós em espera. O PAF também precisa de muito pouca intervenção manual e gerencia a integridade geral de todos os recursos de bancos de dados Postgres. O único caso em que a intervenção manual é um requisito é no caso de uma divergência de dados na linha do tempo em que o usuário pode optar por usar o pg_rewind.

Na Parte 1, discutimos os recursos e o funcionamento do PostgreSQL Automatic Failover (PAF) do ClusterLabs e, na Parte 2, discutiremos os mesmos aspectos de alta disponibilidade usando o Replication Manager for PostgreSQL clusters (repmgr) da 2ndQuadrant. Certifique-se de voltar para a Parte 3, onde também abordaremos o Patroni by Zalando e compararemos as três soluções de código aberto para ajudá-lo a determinar a melhor opção para seu aplicativo.

Na Parte 1 do blog, discutimos os recursos, as práticas recomendadas e o funcionamento do PAF do ClusterLabs e, na postagem do blog da Parte 2, falaremos discuta o mesmo tópico de aspectos de alta disponibilidade usando o Gerenciador de replicação para clusters Postgresql (repmgr) do 2ndQuadrant. Não deixe de conferir nossa postagem do blog na Parte 3, onde também abordaremos o Patroni by Zalando e compararemos todas as três soluções de código aberto para ajudá-lo a determinar as práticas recomendadas e o ajuste ideal para seus aplicativos de negócios.