Primeiros Passos com Alta Disponibilidade no PostgreSQL – Streaming Replication

Neste artigo, vamos mergulhar nos detalhes básicos de configuração do recurso de Streaming Replication no PostgreSQL. A replicação de streaming é o bloco de construção fundamental para alcançar alta disponibilidade em seu Servidor PostgreSQL e é produzida executando uma configuração master-slave.

Terminologia Master-Slave

Servidor Master(Mestre) / Primário

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

Slave(slave) / Standby Server

  • Um servidor onde os dados são mantidos em sincronia com o Master continuamente.
  • Também chamado de servidor de backup ou réplica.
  • Um servidor em espera passiva é aquele ao qual não pode ser conectado até que seja promovido a servidor master.
  • Em contraste, um servidor hot standby pode aceitar conexões e atender a consultas somente leitura. Para o restante desta discussão, nos concentraremos apenas em servidores hot standby.

Os dados são gravados no servidor Master e propagados para os servidores slave ou slaves em ambiente onde temos varias replicas. Caso haja um problema com o servidor Master existente, um dos servidores slaves assumirá e continuará a realizar gravações, garantindo a disponibilidade do sistema.

Replicação baseada WAL

O que é WAL?

  • WAL significa Write-Ahead Logging ou 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 do 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 write-ahead são usados ​​para manter os dados sincronizados entre os servidores de banco de dados. Isto é conseguido de duas maneiras:

Envio de log baseado em arquivo

  • Os arquivos de log do WAL são enviados do Master para os servidores em espera para manter os dados sincronizados.
  • O Master 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 log do 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 Master travar e os registros não forem arquivados

Streaming de registros WAL

  • Os pedaços de registro WAL são transmitidos por servidores de banco de dados para manter os dados sincronizados.
  • O servidor em espera se conecta ao Master para receber os blocos do 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 log 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 artigo, nos concentramos principalmente na replicação de streaming para obter alta disponibilidade do PostgreSQL.

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ó Master

  • Inicialize o banco de dados no nó Master usando o utilitário initdb.
  • Crie uma função / usuário com privilégios de replicação executando o comando abaixo. Após a execução do comando, você pode verificá-lo executando \ du para listá-los no psql.
  • Configure as propriedades relacionadas à replicação de streaming no arquivo de configuração PostgreSQL Master (postgresql.conf): Os valores possíveis são replica | minimal | lógical
  • Adicione a entrada de replicação no arquivo pg_hba.conf para permitir conexões de replicação entre os servidores:

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

Configuração no (s) nó (s) em espera

  • Crie o backup básico do nó Master 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

A opção -X é usada para incluir os arquivos de log de transações necessários (arquivos WAL) na
cópia de segurança.

Quando você especifica o fluxo, isso abre uma segunda conexão com o servidor, e comecça a transmitir o log de transações ao mesmo tempo em que executa o backup.

-c é a opção de ponto de verificação. Definir como rápido forçará o checkpoint a ser
criado em breve.

-W força o pg_basebackup a solicitar uma senha antes de conectar para um banco de dados.

  • Crie o arquivo de configuração de replicação se não estiver presente (ele será criado automaticamente se a opção -R for fornecida em pg_basebackup:
  • Especificar se o servidor deve ser iniciado em espera. Na replicação de streaming, com este parâmetro deve ser definido como on.
  • Especificar uma string de conexão que é usada para o servidor em espera se conectar com o primário / mestre.
  • Especificar a recuperação para uma linha do tempo em particular. O padrão é recuperar ao longo da mesma linha do tempo atual quando o backup básico foi feito.
  • Definir a último time de recuperação para a última linha do tempo encontrada no arquivo, o que é útil em um servidor em espera.
  • Inicie o modo de espera.

A configuração em espera deve ser feita em todos os servidores em espera. Assim que a configuração for concluída e um modo de espera for iniciado, ele se conectará ao Master 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 desejar torná-lo síncrono, você pode configurá-lo usando os seguintes parâmetros:

– num_sync é o número de esperas síncronas das quais transações precisa esperar por respostas.

– standby_name é igual ao valor do application_name em recovery.conf

– Se todos os servidores em espera tiverem que ser considerados síncronos, defina o valor ‘*’]

– Se apenas servidores em espera específicos precisam ser considerados, especifique-os como lista separada por vírgulas em standby_name.

– O nome de um servidor em espera para este propósito é a configuração application_name do standby, conforme definido no primary_conninfo doreceptor WAL em espera.

Synchronous_commit deve ser definido como on para replicação síncrona e este é o padrão. O PostgreSQL fornece opções muito flexíveis para confirmação síncrona e pode ser configurado nos 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 WAL nesse nó.
  • Local – a confirmação da transação é confirmada para o cliente somente depois que o registro da transação é descarregado no arquivo de log do WAL nesse nó.
  • Remote_write – A confirmação da transação é confirmada para o cliente apenas depois que o (s) servidor (es) especificado (s) por synchronous_standby_names confirmam que o registro da transação foi gravado no cache de disco, mas não necessariamente após ser liberado para o arquivo de log WAL.
  • Ativado – a confirmação da transação é confirmada para o cliente somente depois que o (s) servidor (es) especificado (s) por synchronous_standby_names confirmam que o registro da transação é liberado para o arquivo de log WAL.
  • Remote_apply – A confirmação da transação é confirmada para o cliente somente depois que o (s) servidor (es) especificado (s) por synchronous_standby_names confirmam que o registro da transação é liberado para o arquivo de log WAL e aplicado ao banco de dados.

Definir synchronous_commit como off ou local no modo de replicação síncrona fará com que funcione como assíncrono e pode ajudá-lo a obter um melhor desempenho de gravação. No entanto, isso terá maior risco de perda de dados e atrasos na leitura em servidores em espera. Se definido como remote_apply, garantirá a disponibilidade imediata dos dados em 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 tem benefícios extras. Se o modo de arquivamento não estiver ativado , precisamos usar o recurso de slots de replicação ou garantir que o valor wal_keep_segments seja alto o suficiente com base na carga.

Em nossa próxima postagem do blog, apresentaremos o mundo das ferramentas usadas para gerenciar alta disponibilidade para PostgreSQL usando replicação de streaming.

Deixe um comentário

O seu endereço de e-mail não será publicado.