Pesquisa de site

Como configurar a replicação de streaming do PostgreSQL 12 no CentOS 8

O banco de dados PostgreSQL suporta diversas soluções de replicação para construir aplicativos de alta disponibilidade, escaláveis e tolerantes a falhas, um dos quais é o Write-Ahead Log (WAL ) Envio. Esta solução permite que um servidor em espera seja implementado usando envio de log baseado em arquivo ou replicação de streaming ou, quando possível, uma combinação de ambas as abordagens.

Com a replicação de streaming, um servidor de banco de dados em espera (escravo de replicação) é configurado para se conectar ao servidor mestre/primário, que transmite registros WAL para o modo de espera à medida que são gerados, sem esperar pelo WAL arquivo a ser preenchido.

Por padrão, a replicação de streaming é assíncrona, onde os dados são gravados no(s) servidor(es) em espera após uma transação ter sido confirmada no servidor primário. Isso significa que há um pequeno atraso entre a confirmação de uma transação no servidor mestre e as alterações se tornarem visíveis no servidor standby. Uma desvantagem dessa abordagem é que, caso o servidor mestre trave, quaisquer transações não confirmadas poderão não ser replicadas e isso poderá causar perda de dados.

Este guia mostra como configurar uma replicação de streaming master-standby do Postgresql 12 no CentOS 8. Usaremos “slots de replicação ” para o standby como uma solução para evitar que o servidor mestre recicle segmentos WAL antigos antes que o standby os receba.

Observe que, em comparação com outros métodos, os slots de replicação retêm apenas o número de segmentos considerados necessários.

Ambiente de teste:

Este guia pressupõe que você esteja conectado aos servidores de banco de dados mestre e standby como root via SSH (use o comando Sudo quando necessário se você estiver conectado como um usuário normal com direitos administrativos):

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

Ambos os servidores de banco de dados devem ter o Postgresql 12 instalado, caso contrário, consulte: Como instalar o PostgreSQL e o pgAdmin no CentOS 8.

Observação: o PostgreSQL 12 vem com grandes mudanças na implementação e configuração da replicação, como a substituição de recovery.conf e a conversão dos parâmetros recovery.conf em parâmetros normais de configuração do PostgreSQL, tornando muito mais fácil configurar a replicação do cluster.

Etapa 1: Configurando o servidor de banco de dados mestre/primário PostgreSQL

1. No servidor mestre, mude para a conta do sistema postgres e configure os endereços IP nos quais o servidor mestre escutará as conexões dos clientes.

Neste caso, usaremos * significando todos.

su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

O comando SQL ALTER SYSTEM SET é um recurso poderoso para alterar os parâmetros de configuração de um servidor, diretamente com uma consulta SQL. As configurações são salvas no arquivo postgresql.conf.auto localizado na raiz da pasta de dados (por exemplo, /var/lib/pgsql/12/data/) e lidas adicionalmente àqueles armazenados em postgresql.conf. Mas as configurações do primeiro têm precedência sobre as do último e de outros arquivos relacionados.

2. Em seguida, crie uma função de replicação que será usada para conexões do servidor standby ao servidor mestre, usando o programa createuser. No comando a seguir, o sinalizador -P solicita uma senha para a nova função e -e ecoa os comandos que createuser gera e envia ao servidor de banco de dados.

su – postgres
createuser --replication -P -e replicator
exit

3. Em seguida, insira a seguinte entrada no final do arquivo de configuração de autenticação do cliente /var/lib/pgsql/12/data/pg_hba.conf com o campo do banco de dados definido como replicação conforme mostrado na captura de tela.

host    replication     replicator      10.20.20.8/24     md5

4. Agora reinicie o serviço Postgres12 usando o seguinte comando systemctl para aplicar as alterações.

systemctl restart postgresql-12.service

5. Em seguida, se você tiver o serviço firewalld em execução, será necessário adicionar o serviço Postgresql na configuração do firewalld para permitir solicitações do servidor standby para o mestre.

firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Etapa 2: Fazendo um backup básico para inicializar o servidor standby

6. Em seguida, você precisa fazer um backup básico do servidor master a partir do servidor standby; isso ajuda a inicializar o servidor em espera. Você precisa interromper o serviço postgresql 12 no servidor em espera, mudar para a conta de usuário postgres, fazer backup do diretório de dados (/var/lib/pgsql/12/data/) e excluir tudo abaixo dele conforme mostrado, antes de fazer o backup básico.

systemctl stop postgresql-12.service
su - postgres
cp -R /var/lib/pgsql/12/data /var/lib/pgsql/12/data_orig
rm -rf /var/lib/pgsql/12/data/*

7. Em seguida, use a ferramenta pg_basebackup para fazer o backup base com a propriedade correta (o usuário do sistema de banco de dados, ou seja, Postgres, dentro do conta de usuário Postgres) e com as permissões corretas.

No comando a seguir, a opção:

  • -h – especifica o host que é o servidor mestre.
  • -D – especifica o diretório de dados.
  • -U – especifica o usuário da conexão.
  • -P – permite relatórios de progresso.
  • -v – ativa o modo detalhado.
  • -R – permite a criação de configuração de recuperação: Cria um arquivo standby.signal e anexa configurações de conexão a postgresql.auto.conf sob os dados diretório.
  • -X – usado para incluir os arquivos de log write-ahead necessários (arquivos WAL) no backup. Um valor de stream significa transmitir o WAL enquanto o backup é criado.
  • -C – permite a criação de um slot de replicação nomeado pela opção -S antes de iniciar o backup.
  • -S – especifica o nome do slot de replicação.
pg_basebackup -h 10.20.20.9 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
exit

8. Quando o processo de backup for concluído, o novo diretório de dados no servidor em espera deverá ser semelhante ao da captura de tela. Um standby.signal é criado e as configurações de conexão são anexadas a postgresql.auto.conf. Você pode listar seu conteúdo usando o comando ls.

ls -l /var/lib/pgsql/12/data/

Um escravo de replicação será executado no modo “Hot Standby ” se o parâmetro hot_standby estiver ativado (o valor padrão) em postgresql.conf e existe um arquivo standby.signal presente no diretório de dados.

9. Agora, de volta ao servidor mestre, você poderá ver o slot de replicação chamado pgstandby1 ao abrir a visualização pg_replication_slots conforme a seguir.

su - postgres
psql -c "SELECT * FROM pg_replication_slots;"
exit

10. Para visualizar as configurações de conexão anexadas ao arquivo postgresql.auto.conf, use o comando cat.

cat /var/lib/pgsql/12/data/postgresql.auto.conf

11. Agora inicie as operações normais do banco de dados no servidor standby iniciando o serviço PostgreSQL da seguinte maneira.

systemctl start postgresql-12

Etapa 3: Testando a replicação de streaming do PostgreSQL

12. Assim que uma conexão for estabelecida com sucesso entre o mestre e o standby, você verá um processo receptor WAL no servidor standby com status de streaming, você pode verificar isso usando a visualização pg_stat_wal_receiver.

psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

e um processo remetente WAL correspondente no servidor mestre/primário com um estado de streaming e um sync_state de assíncrono, você pode verificar esta visualização pg_stat_replication pg_stat_replication.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Na captura de tela acima, a replicação de streaming é assíncrona. Na próxima seção, demonstraremos como habilitar opcionalmente a replicação síncrona.

13. Agora teste se a replicação está funcionando bem criando um banco de dados de teste no servidor master e verifique se ele existe no servidor standby.
[master]postgres=# CRIAR BANCO DE DADOS tecmint;
[em espera]postgres=#\l

Opcional: Habilitando a Replicação Síncrona

14. A replicação síncrona oferece a capacidade de confirmar uma transação (ou gravar dados) no banco de dados primário e no standby/réplica simultaneamente. Ele só confirma que uma transação foi bem-sucedida quando todas as alterações feitas pela transação foram transferidas para um ou mais servidores em espera síncronos.

Para ativar a replicação síncrona, o synchronous_commit também deve estar ativado (que é o valor padrão, portanto, não há necessidade de qualquer alteração) e você também precisa definir o parâmetro synchronous_standby_names para um valor não vazio. Para este guia, iremos configurá-lo para todos.

psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

15. Em seguida, recarregue o serviço PostgreSQL 12 para aplicar as novas alterações.

systemctl reload postgresql-12.service

16. Agora, quando você consultar o processo remetente WAL no servidor primário mais uma vez, ele deverá mostrar um estado de streaming e um sync_state de < forte>sincronizar.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Chegamos ao final deste guia. Mostramos como configurar a replicação de streaming de banco de dados master-standby do PostgreSQL 12 no CentOS 8. Também abordamos como habilitar a replicação síncrona em um cluster de banco de dados PostgreSQL.

Há muitos usos para replicação e você sempre pode escolher uma solução que atenda ao seu ambiente de TI e/ou aos requisitos específicos da aplicação. Para obter mais detalhes, acesse Log-Shipping Standby Servers na documentação do PostgreSQL 12.