Gerenciando alta disponibilidade no PostgreSQL – Parte II:Gerenciador de replicação

Você está implantando o PostgreSQL na nuvem e quer entender suas opções para obter alta disponibilidade? Em nossa postagem anterior no blog, Gerenciando alta disponibilidade no PostgreSQL – Parte I, discutimos os recursos e o funcionamento do PostgreSQL Automatic Failover (PAF) do ClusterLabs. Na Parte II, apresentamos uma ferramenta alternativa de código aberto, Replication Manager do 2ndQuadrant, a ser seguida de perto pela Parte III, onde mergulhamos em nossa terceira alternativa, Patroni by Zalando.

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

Gerenciador de replicação (repmgr)

repmgr é um conjunto de ferramentas de código aberto desenvolvido pela 2ndQuadrant para gerenciar a replicação e o failover de seus clusters PostgreSQL. Ele fornece as ferramentas para configurar, configurar, gerenciar e monitorar a replicação do PostgreSQL e também permite que você execute tarefas manuais de alternância e failover usando o utilitário repmgr. Esta ferramenta gratuita suporta e aprimora a replicação de streaming integrada do PostgreSQL.

O Replication Manager fornece duas ferramentas principais para gerenciar a replicação e o failover do PostgreSQL.

repmgr

Um utilitário de interface de linha de comando que permite executar várias tarefas administrativas.
repmgr permite configurar servidores em espera, promover esperas, fazer uma alternância e monitorar o status de seu cluster PostgreSQL.
Ele também fornece a opção de simulação para quase todos os comandos administrativos.

repmgrd

Este é o daemon que:

Monitora ativamente os clusters do PostgreSQL e executa as ações necessárias com base no estado do cluster.
Executa failover automático caso o nó principal fique inativo, promovendo o modo de espera mais qualificado como o novo principal.
Fornece uma opção para monitorar e armazenar os dados relacionados ao desempenho da replicação.
Fornece notificação invocando os scripts do usuário para eventos registrados.

Como funciona

repmrg não apenas gerencia a replicação de clusters PostgreSQL, mas também tem recursos para configurar os servidores em espera para replicação. Após a instalação inicial, precisamos fazer alterações no arquivo de configuração repmgr (repmgr.conf) com os detalhes necessários em cada servidor. Quando um servidor é configurado, ele precisa ser registrado com repmgr usando o comando repmgr primary/standby register. Primeiro, o nó primário é configurado e registrado. Em seguida, os servidores standby são criados e configurados usando o comando repmgr standby clone que clona o nó standby do PostgreSQL de outro servidor PostgreSQL.

O Replication Manager faz uso do recurso de extensões do PostgreSQL e cria seu próprio esquema no banco de dados do cluster para armazenar as informações relacionadas ao cluster. A instalação da extensão e a criação do esquema acontecem durante o registro do servidor primário usando repmgr. Depois que a configuração estiver concluída, as operações administrativas manuais, como promover, seguir, alternar, etc., podem ser feitas usando o utilitário repmgr. Para operação de alternância, requer que o SSH sem senha seja configurado entre os nós.

O failover automático pode ser configurado usando repmgrd. O repmgrd requer que uma biblioteca compartilhada ‘repmgr’ seja carregada no momento da inicialização do servidor PostgreSQL. O nome da biblioteca deve ser mencionado nas shared_preload_libraries parâmetro de configuração no arquivo postgresql.conf. Além disso, para que repmgrd funcione, failover=automatic parâmetro precisa ser definido no arquivo repmgr.conf. Depois que todos esses parâmetros são definidos, o daemon repmgrd começa a monitorar ativamente o cluster. Se houver alguma falha no nó primário, ele tentará se reconectar várias vezes. Quando todas as tentativas de conexão ao primário falham, o standby mais elegível é escolhido por eleição como o novo primário pelo repmgrd.

repmgr também suporta notificações de eventos. Possui um conjunto de eventos predefinidos e armazena cada ocorrência desses eventos na tabela repmgr.events. repmgr permite que notificações de eventos sejam passadas para um programa ou script definido pelo usuário que pode executar ações adicionais, como enviar um e-mail ou acionar qualquer alerta. Isso é feito definindo o event_notification_command parâmetro em repmgr.conf.

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

repmgr enfrenta cenários de cérebro dividido usando o local parâmetro, onde cada nó deve especificar o parâmetro de localização com base no datacenter em que está colocado. No caso de qualquer divisão de rede, o repmgr garantirá a promoção do nó que está no mesmo local que o primário. Se não encontrar nenhum nó nesse local, ele não promoverá nenhum nó em nenhum local.

Ele também lida com o isolamento da rede no caso de um número par de servidores em um cluster. Isso é feito usando um nó extra chamado servidor testemunha. O servidor testemunha é um nó que é considerado apenas para a contagem de votos da maioria. Não haverá instalação do PostgreSQL nesse servidor e, portanto, não haverá papel na replicação.

Existem requisitos de configuração?

repmgr exigirá um banco de dados dedicado e um usuário com privilégios de superusuário. No entanto, também há uma opção para fornecer um superusuário se você não estiver disposto a conceder ao superusuário acesso ao usuário repmgr.
Se você quiser que o repmgr copie os arquivos de configuração localizados fora do diretório de dados do PostgreSQL e/ou para testar a funcionalidade de alternância, você também precisará de conexões SSH sem senha entre os dois servidores e rsync deve ser instalado.
Se você pretende usar comandos baseados em serviço diferentes de pg_ctl (que é usado por repmgr por padrão) para iniciar, parar, recarregar e reiniciar, você pode especificá-los em repmgr arquivo de configuração (repmgr.conf).

Os parâmetros básicos de configuração necessários no arquivo de configuração repmgr são os seguintes:

node_id (int) – Um inteiro único maior que zero que identifica o nó.node_name (string) – Uma string arbitrária (mas única), usando o nome do host do servidor ou outro identificador inequivocamente associado ao servidor, é recomendado para evitar confusão.

conninfo (string) – Informações de conexão do banco de dados como uma string conninfo. Todos os servidores no cluster devem ser capazes de se conectar ao nó local usando essa string.

data_directory (string) – O diretório de dados do nó. Isso é necessário pelo repmgr para realizar operações quando a instância do PostgreSQL não está em execução e não há outra maneira de determinar o diretório de dados.

Prós do repmgr

Repmgr fornece utilitários que ajudam a configurar nós primários e em espera e configurar a replicação.
Não usa nenhuma porta extra para comunicação. Se você quiser realizar a alternância, só então será necessário configurar o SSH sem senha.
Fornece uma notificação invocando os scripts do usuário para os eventos registrados.
Executa failover automático em caso de falha do servidor primário.

Repmgr Contras

repmgr não detecta se o standby está mal configurado com um nó desconhecido ou inexistente na configuração de recuperação. O nó será mostrado como em espera mesmo se estiver sendo executado sem se conectar ao nó principal/em cascata em espera.
Não é possível recuperar o status de outro nó de um nó onde o serviço PostgreSQL está inativo. Portanto, ele não fornece uma solução de controle distribuído.
Ele não lida com a recuperação da integridade de nós individuais.

Gerenciando a alta disponibilidade no #PostgreSQL – Parte II:Ferramenta repmgr de código aberto Clique para tuitar

Cenários de teste de alta disponibilidade

Realizamos alguns testes no gerenciamento de alta disponibilidade do PostgreSQL usando repmgr. Todos esses testes foram executados enquanto a aplicação estava rodando 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	O servidor em espera foi marcado como com falha. Não houve interrupção na aplicação do gravador. A intervenção manual foi necessária para iniciar o processo do PostgreSQL novamente.
2	Parar o processo do PostgreSQL	O servidor em espera foi marcado como com falha. Não houve interrupção na aplicação do gravador. A intervenção manual foi necessária para iniciar o processo do PostgreSQL novamente.
3	Reinicialize o servidor	O servidor em espera foi marcado como com falha. 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 no aplicativo do gravador.
4	Parar o processo 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 no aplicativo do gravador.

Testes do servidor mestre/primário

Sl. Não	Cenário de teste	Observação
1	Eliminar o processo PostgreSQL	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, a reserva que teve o último LSN recebido foi promovida. 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. Houve tempo de inatividade no aplicativo de gravação. A intervenção manual foi necessária para iniciar o processo do PostgreSQL novamente.
2	Parar o processo do PostgreSQL e trazê-lo de volta imediatamente após a expiração da verificação de integridade	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 falhavam, uma eleição era acionada em todos os nós em espera. No entanto, o mestre recém-eleito não notificou os servidores em espera existentes, pois o antigo mestre estava de volta. O cluster foi deixado em um estado indeterminado e a intervenção manual foi necessária.
3	Reinicialize o servidor	repmgrd iniciou a eleição quando a verificação de integridade da conexão principal falhou em todos os servidores em espera. A espera qualificada foi promovida. Quando este servidor voltou, ele não ingressou no cluster e foi marcado com falha. O comando repmgr node rejoin foi executado para adicionar o servidor de volta ao cluster. Houve tempo de inatividade no aplicativo de gravação.
4	Parar o processo repmgr	O servidor principal não fará parte da situação de failover automatizado. O serviço PostgreSQL foi encontrado em execução. Não houve interrupção no aplicativo do gravador.

Testes de isolamento de rede

Sl. Não	Cenário de teste	Observação
1	A rede isola o servidor primário de outros servidores (todos têm o mesmo valor para localização na configuração do repmgr)	repmgrd iniciou a eleição quando a verificação de integridade da conexão principal falhou em todos os servidores em espera. A espera elegível foi promovida, mas o processo do PostgreSQL ainda estava em execução no antigo nó mestre. Havia dois nós em execução como mestre. A intervenção manual foi necessária após a correção do isolamento da rede.
2	A rede isola o servidor principal de outros servidores (os servidores em espera têm o mesmo valor para localização, mas o principal tem um valor diferente para localização na configuração do repmgr)	repmgrd iniciou a eleição quando a verificação de integridade da conexão principal falhou em todos os servidores em espera. Mas não foi eleito um novo mestre, pois os servidores em espera tinham um local diferente do primário. repmgrd entrou no modo de monitoramento de degradação. O PostgreSQL estava sendo executado em todos os nós e havia apenas um mestre no cluster.

Inferência

repmgr fornece vários comandos para configurar e monitorar a replicação do PostgreSQL. É rico em recursos e também facilita o trabalho do administrador de banco de dados (DBA). No entanto, não é uma ferramenta de gerenciamento de alta disponibilidade completa, pois não gerenciará os recursos. A intervenção manual é necessária para garantir que o recurso esteja no estado adequado.

Então, neste post, discutimos os recursos e o funcionamento do Replication Manager do 2ndQuadrant. Em nosso próximo post, discutiremos os mesmos aspectos de alta disponibilidade usando Patroni by Zalando. Para usuários que desejam automatizar sua alta disponibilidade na nuvem, confira nossas soluções totalmente gerenciadas PostgreSQL no Azure e PostgreSQL na AWS.