Gerenciar alta disponibilidade em sua hospedagem PostgreSQL é muito importante para garantir que seus clusters mantenham um tempo de atividade excepcional e um forte desempenho operacional para que seus dados estejam sempre disponíveis para o seu aplicativo.
Existem várias ferramentas disponíveis para gerenciar a alta disponibilidade de seus clusters do PostgreSQL usando a replicação de streaming. Essas soluções oferecem recursos automáticos de failover, monitoramento, replicação e outras tarefas administrativas úteis. Algumas das soluções proeminentes de código aberto incluem:
- Failover automático do PostgreSQL por ClusterLabs
- Gerenciador de replicação para clusters do PostgreSQL por repmgr (2ndQuadrant)
- Patroni de Zalando
Cada uma dessas ferramentas fornece seu próprio modo de gerenciar os clusters. Em nossa série de três postagens em alta disponibilidade para o 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 de Failover Automático do PostgreSQL (PAF) pelo ClusterLabs.
Failover automático do PostgreSQL
O Failover Automático do PostgreSQL (PAF) é uma solução de gerenciamento de alta disponibilidade para PostgreSQL da ClusterLabs. O PAF faz uso do popular Pacemaker e do Corosync, padrão da indústria. Com o Pacemaker e o Corosync juntos, você poderá detectar falhas no sistema e agir de acordo.
O marcapasso é capaz de gerenciar muitos recursos e o faz 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 devem se comportar e informar o Pacemaker sobre seus resultados.
A implementação do seu agente de recursos deve estar de acordo com a especificação do 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 interação com o Marcapasso.
O PAF é um agente de recursos OCF para PostgreSQL escrito em Perl. Uma vez que seu cluster do PostgreSQL é construído usando a replicação de streaming interna, o PAF é capaz de expor ao Pacemaker o status atual da instância do PostgreSQL em cada nó: mestre, escravo, parado, recuperação, etc.
Como funciona
O PAF se comunica com o Pacemaker em relação ao status do cluster e monitora o funcionamento do PostgreSQL. No caso de uma falha, ele informa o Pacemaker, e se não houver chance de o mestre atual ser recuperado, ele acionará uma eleição entre os servidores em espera atuais. Com o robusto Pacemaker instalado, o PAF realizará ações de gerenciamento como iniciar, parar, monitorar e failover em todos os nós do PostgreSQL.
Há algum requisito de instalação?
- O PAF suporta a versão 9.3 e superior do PostgreSQL.
- O PAF não é responsável pela criação do mestre / espera do PostgreSQL ou pela sua configuração - você deve criar e configurar a replicação de streaming antes de usar o PAF.
- O PAF não edita qualquer configuração do Postgres. No entanto, exige que os usuários sigam alguns pré-requisitos, como:
- Escravo deve ser configurado como hot standby.
- Um arquivo de modelo de recuperação (padrão:
/recovery.conf.pcmk) deve ser fornecido com os parâmetros abaixo: - standby_mode = on
- recovery_target_timeline = ‘latest’
- primary_conninfo deve ter o parâmetro application_name definido e configurado para o nome do nó local como no Pacemaker.
- O PAF expõe vários parâmetros relacionados ao gerenciamento de um recurso do PostgreSQL. Isso pode ser configurado para atender às necessidades de cada um. Abaixo estão os parâmetros:
- bindir: localização dos binários do PostgreSQL (padrão: /usr/bin)
- pgdata: localização do PGDATA da sua instância (padrão: / var / lib / pgsql / data)
- datadir: caminho para o diretório definido no data_directory a partir 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 conectar-se à 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 do Postgres na inicialização. Veja “postgres –help” para opções disponíveis. Útil quando o arquivo postgresql.conf não está no diretório de dados (PGDATA), por exemplo: -c config_file = / etc / postgresql / 9.3 / main / postgresql.conf
- system_user: o proprietário do sistema do processo da sua instância (padrão: postgres)
- maxlag: atraso máximo permitido em uma espera antes de definirmos uma pontuação mestre negativa
PAF Pros
- O PAF fornece ao usuário uma configuração prática e configuração do PostgreSQL.
- O PAF pode manipular falhas de nó e disparar eleições quando o mestre é desativado.
- O comportamento do quórum pode ser aplicado no PAF.
- Ele fornecerá uma solução completa de gerenciamento de alta disponibilidade para o recurso, incluindo iniciar, parar e monitorar, além de 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 PAF
- O PAF não detecta se uma espera está configurada 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 do Pacemaker e do Corosync usando o UDP.
- Não suporta configuração baseada em NAT.
- Nenhum suporte pg_rewind.
Cenários de teste de alta disponibilidade
Realizamos alguns testes para determinar a capacidade do gerenciamento de HA do PostgreSQL usando o PAF. Todos esses testes foram executados enquanto o aplicativo estava em execução e inserindo dados no banco de dados PostgreSQL. O aplicativo foi escrito usando o driver JDBC do PostgreSQL Java, aproveitando o recurso de failover de conexão.
Testes do servidor em espera
| N | Cenário | Observação |
|---|---|---|
| 1 | Mate o processo do PostgreSQL | O marcapasso trouxe o processo do PostgreSQL de volta ao estado de execução. Não houve interrupção na aplicação do gravador. |
| 2 | Pare o processo do PostgreSQL | O marcapasso trouxe o processo do PostgreSQL de volta ao estado de execução. Não houve interrupção na aplicação do gravador. |
| 3 | Reinicie o servidor | O servidor em espera foi marcado como offline inicialmente. Uma vez que o servidor surgiu após a reinicialização, o PostgreSQL foi iniciado pelo Pacemaker e o servidor foi marcado como online. Se o fence estivesse habilitado, o nó não teria sido adicionado automaticamente ao cluster. Não houve interrupção na aplicação do gravador. |
| 4 | Pare o processo do marcapasso | Ele também interromperá o processo do PostgreSQL e o servidor será marcado como off-line. Não houve interrupção na aplicação do gravador. |
Testes do servidor principal / principal
| N | Cenário | Observação |
|---|---|---|
| 1 | Mate o processo do PostgreSQL | O marcapasso trouxe o processo do PostgreSQL de volta ao estado de execução. A primária foi recuperada dentro do tempo limite e, portanto, a eleição não foi acionada. O aplicativo gravador ficou inativo por cerca de 26 segundos. |
| 2 | Pare o processo do PostgreSQL | O marcapasso trouxe o processo do PostgreSQL de volta ao estado de execução. A primária foi recuperada dentro do tempo limite e, portanto, a eleição não foi acionada. Houve um tempo de inatividade no aplicativo do gravador por cerca de 26 segundos. |
| 3 | Reinicie o servidor | A eleição foi acionada pelo marcapasso 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. Uma vez que o antigo mestre surgiu após a reinicialização, ele foi adicionado novamente ao cluster como um standby. Se o fence estivesse habilitado, o nó não teria sido adicionado automaticamente ao cluster. O aplicativo gravador ficou inativo por cerca de 26 segundos. |
| 4 | Pare o processo do marcapasso | Ele também interromperá o processo do PostgreSQL e o servidor será marcado como off-line. A eleição será acionada e o novo mestre será eleito. Houve tempo de inatividade na aplicação do gravador. |
Testes de isolamento de rede
| N | Cenário | Observação |
|---|---|---|
| 1 | Rede isola o servidor em espera de outros servidores | O tráfego do Corosync foi bloqueado no servidor em espera. O servidor foi marcado como off-line e o serviço PostgreSQL foi desativado devido à política de quorum. Não houve interrupção no aplicativo do gravador. |
| 2 | Rede isola o servidor mestre de outros servidores (cenário de cérebro dividido) | O tráfego do Corosync foi bloqueado no servidor mestre. O serviço PostgreSQL foi desativado e o servidor principal foi marcado como off-line devido à política de quorum. Um novo mestre foi eleito na partição majoritária. Houve um tempo de inatividade no aplicativo do gravador. |
Testes Diversos
| N | Cenário | Observação |
|---|---|---|
| 1 | Degrade o cluster desativando todos os servidores em espera. | Quando todos os servidores em espera foram desativados, o serviço PostgreSQL no principal foi interrompido devido à política de quorum. Após esse teste, quando todos os servidores em espera foram ativados, um novo mestre foi eleito. Houve um tempo de inatividade no aplicativo do gravador. |
| 2 | Aleatoriamente desligue todos os servidores um após o outro, começando com o mestre, e traga-os 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 do gravador. |
Inferência
O Failover Automático do PostgreSQL oferece várias vantagens no tratamento da alta disponibilidade do PostgreSQL. O PAF usa o failover de endereço IP em vez de reinicializar a 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 saúde geral de todos os recursos. O único caso em que a intervenção manual é um requisito é no caso de uma divergência na linha de tempo em que o usuário pode optar por usar o pg_rewind .
Na Parte 1, discutimos os recursos e o funcionamento do Failover Automático do PostgreSQL (PAF) pelo ClusterLabs e, na Parte 2, discutiremos os mesmos aspectos de alta disponibilidade usando o Replication Manager para clusters do PostgreSQL (repmgr) pelo 2ndQuadrant. Não deixe de conferir a Parte 3, onde também abordaremos Patroni by Zalando e compararemos as três soluções de código aberto para ajudá-lo a determinar o melhor ajuste para sua aplicação.