Nesta postagem do blog, aprofundamos os detalhes básicos da configuração da Streaming Replication (SR) no PostgreSQL. A replicação de streaming é o bloco de construção fundamental para alcançar alta disponibilidade em sua hospedagem PostgreSQL e é produzida pela execução de uma configuração mestre-escravo.

Terminologia mestre-escravo

Mestre/Servidor Primário

• O servidor que pode receber gravações.
• Também chamado de servidor de leitura/gravação.

Servidor escravo/em espera

• Um servidor onde os dados são mantidos em sincronia com o mestre continuamente.
• Também chamado de servidor de backup ou réplica.
• Um servidor de espera quente é aquele que não pode ser conectado até que seja promovido a servidor mestre.
• Por outro lado, um servidor de espera ativa pode aceitar conexões e atender a consultas somente leitura. No restante desta discussão, focaremos apenas em servidores de espera ativa.

Os dados são gravados no servidor mestre e propagados para os servidores escravos. Caso haja algum problema com o servidor mestre existente, um dos servidores escravos assumirá o controle e continuará fazendo gravações garantindo a disponibilidade do sistema.

Replicação baseada em envio WAL

O que é WAL?

• WAL significa registro de gravação antecipada.
• É um arquivo de log onde todas as modificações no banco de dados são gravadas antes de serem aplicadas/gravadas nos arquivos de dados.
• O WAL é usado para recuperação após uma falha no banco de dados, garantindo a integridade dos dados.
• O WAL é usado em sistemas de banco de dados para obter atomicidade e durabilidade.

Como o WAL é usado para replicação?

Os registros de log de gravação antecipada são usados ​​para manter os dados sincronizados entre os servidores de banco de dados. Isto é conseguido de duas maneiras:

Envio de logs com base em arquivo

• Os arquivos de log do WAL são enviados do mestre para os servidores em espera para manter os dados sincronizados.
• O mestre pode copiar diretamente os logs para o armazenamento do servidor em espera ou pode compartilhar o armazenamento com os servidores em espera.
• Um arquivo de registro WAL pode conter até 16 MB de dados.
• O arquivo WAL é enviado somente após atingir esse limite.
• Isso causará um atraso na replicação e também aumentará as chances de perda de dados se o mestre travar e os logs não forem arquivados

Transmissão de registros WAL

• Os fragmentos de registro WAL são transmitidos por servidores de banco de dados para manter os dados sincronizados.
• O servidor em espera se conecta ao mestre para receber os fragmentos WAL.
• Os registros WAL são transmitidos à medida que são gerados.
• O streaming de registros WAL não precisa esperar que o arquivo WAL seja preenchido.
• Isso permite que um servidor em espera fique mais atualizado do que é possível com o envio de logs baseado em arquivo.
• Por padrão, a replicação de streaming é assíncrona, embora também ofereça suporte à replicação síncrona.

Ambos os métodos têm seus prós e contras. O uso do envio baseado em arquivo permite a recuperação pontual e o arquivamento contínuo, enquanto o streaming garante a disponibilidade imediata dos dados nos servidores em espera. No entanto, você pode configurar o PostgreSQL para usar os dois métodos ao mesmo tempo e aproveitar os benefícios. Neste blog, nos concentramos principalmente na replicação de streaming para alcançar a alta disponibilidade do PostgreSQL.
Como configurar a replicação de streaming no PostgreSQL para alta disponibilidadeClick To Tweet

Como configurar a replicação de streaming?

Configurar a replicação de streaming no PostgreSQL é muito simples. Supondo que o PostgreSQL já esteja instalado em todos os servidores, você pode seguir estas etapas para começar:

Configuração no nó mestre

• Inicie o banco de dados no nó mestre usando o utilitário initdb.
• Crie uma função/usuário com privilégios de replicação executando o comando abaixo. Depois de executar o comando, você pode verificá-lo executando \du para listá-los no psql.
  •   CRIAR USUÁRIO SENHA ENCRIPTADA DE LOGIN DE REPLICAÇÃO '';
• Configure as propriedades relacionadas à replicação de streaming no arquivo de configuração mestre do PostgreSQL (postgresql.conf):
  

  # Os valores possíveis são replica|minimal|logical wal_level =replica# necessário para o recurso pg_rewind quando o modo de espera fica fora de sincronia com o mestre wal_log_hints =on# define o número máximo de conexões simultâneas dos servidores em espera. max_wal_senders =3 # O parâmetro abaixo é usado para informar ao mestre para manter o número mínimo de # segmentos de logs WAL para que eles não sejam excluídos antes que o standby os consuma. # cada segmento é 16 MB wal_keep_segments =8 # O parâmetro abaixo habilita a conexão somente leitura no nó quando está em # função de espera. Isso é ignorado quando o servidor está sendo executado como mestre. hot_standby =ativado

• Adicione entrada de replicação no arquivo pg_hba.conf para permitir conexões de replicação entre os servidores:
  

  # Permitir conexões de replicação de localhost, # por um usuário com o privilégio de replicação. # TYPE    DATABASE    USER    ADDRESS    MÉTODO host    replication    repl_user    IPaddress (CIDR)    md5

• Reinicie o serviço PostgreSQL no nó mestre para que as alterações tenham efeito.

Configuração em nós de espera

• Crie o backup básico do nó mestre usando o utilitário pg_basebackup e use-o como ponto de partida para o modo de espera.
  

  # Explicando algumas opções usadas para o utilitário pg_basebackup# -X é usada para incluir os arquivos de log de transações necessários (arquivos WAL) no # backup. Quando você especifica stream, isso abrirá uma segunda conexão com o servidor # e começará a transmitir o log de transações ao mesmo tempo em que executa o backup. # -c é a opção de checkpoint. Configurá-lo para rápido forçará o ponto de verificação a ser # criado em breve. # -W força o pg_basebackup a solicitar uma senha antes de conectar # a um banco de dados. pg_basebackup -D  -h -X stream -c fast -U repl_user -W

• Cria o arquivo de configuração de replicação se não estiver presente (ele é criado automaticamente se a opção -R for fornecida em pg_basebackup):
  

  # Especifica se o servidor deve ser iniciado como uma espera. Na replicação de streaming, # esse parâmetro deve estar ativado. standby_mode ='on'# Especifica uma string de conexão que é usada para que o servidor em espera se conecte # com o primário/mestre. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Especifica a recuperação para uma linha do tempo específica. O padrão é recuperar ao longo da # mesma linha de tempo que estava atual quando o backup básico foi feito. # Definir isso como mais recente recupera para a última linha de tempo encontrada # no arquivo, que é útil em um servidor em espera. recovery_target_timeline ='mais recente'

• Inicie o modo de espera.

A configuração standby deve ser feita em todos os servidores standby. Depois que a configuração estiver concluída e um standby for iniciado, ele se conectará ao mestre e iniciará o streaming de logs. Isso configurará a replicação e pode ser verificado executando a instrução SQL “SELECT * FROM pg_stat_replication; “.

Por padrão, a replicação de streaming é assíncrona. Se você deseja torná-lo síncrono, pode configurá-lo usando os seguintes parâmetros:

Synchronous_commit deve ser definido como ativado para replicação síncrona e esse é o padrão. O PostgreSQL oferece opções muito flexíveis para confirmação síncrona e pode ser configurado em níveis de usuário/banco de dados. Os valores válidos são os seguintes:

• Desativado – A confirmação da transação é confirmada para o cliente antes mesmo que o registro da transação seja realmente liberado para o arquivo de log do WAL nesse nó.
• Local –  A confirmação da transação é confirmada para o cliente somente depois que esse registro de transação é liberado no arquivo de log do WAL nesse nó.
• Escrita_remoto – A confirmação da transação é confirmada para o cliente somente após o(s) servidor(es) especificado(s) por synchronous_standby_names confirmar que o registro da transação foi gravado no cache de disco, mas não necessariamente após ser liberado no arquivo de log do WAL.
• Ativado – A confirmação da transação é confirmada para o cliente somente após o(s) servidor(es) especificado(s) por synchronous_standby_names confirmar que o registro da transação foi liberado para o arquivo de log do WAL.
• Remote_apply – A confirmação da transação é confirmada para o cliente somente após o(s) servidor(es) especificado(s) por synchronous_standby_names confirmar que o registro da transação foi liberado para o arquivo de log do WAL e aplicado ao banco de dados.

Configurar synchronous_commit como desativado ou local no modo de replicação síncrona fará com que funcione como assíncrono e pode ajudar você a obter um melhor desempenho de gravação. No entanto, isso terá maior risco de perda de dados e atrasos de leitura em servidores em espera. Se definido como remote_apply, ele garantirá a disponibilidade imediata dos dados nos servidores em espera, mas o desempenho de gravação pode diminuir, pois deve ser aplicado em todos/os servidores em espera mencionados.

Você pode habilitar o modo de arquivamento se estiver planejando usar arquivamento contínuo e recuperação pontual. Embora não seja obrigatório para a replicação de streaming, habilitar o modo de arquivamento traz benefícios extras. Se o modo de arquivamento não estiver ativado, precisamos usar os espaços de replicação recurso ou garantir que wal_keep_segments valor é definido alto o suficiente com base na carga.

Consulte esta excelente apresentação para obter mais detalhes sobre alta disponibilidade no PostgreSQL. Em nossa próxima postagem do blog, apresentaremos o mundo das ferramentas usadas para gerenciar a alta disponibilidade do PostgreSQL usando a replicação de streaming.