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.

CREATE USER <user_name> REPLICATION LOGIN ENCRYPTED PASSWORD ’<password>’;

# Possible values are replica|minimal|logical
wal_level = replica
# required for pg_rewind capability when standby goes out of sync with master
wal_log_hints = on
# sets the maximum number of concurrent connections from the standby servers.
max_wal_senders = 3
# The below parameter is used to tell the master to keep the minimum number of
# segments of WAL logs so that they are not deleted before standby consumes them.
# each segment is 16MB
wal_keep_segments = 8
# The below parameter enables read only connection on the node when it is in
# standby role. This is ignored when the server is running as master.
hot_standby = on

• 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

wal_level = replica - Os valores possíveis são réplica | mínimo | lógico
wal_log_hints = on - Necessário para o recurso pg_rewind quando o modo de espera sair de sincronia com o mestre
wal_log_hints = on - Define o número máximo de conexões simultâneas dos servidores em espera.
wal_keep_segments - O parâmetro abaixo é usado para dizer ao mestre para manter o número mínimo de segmentos de logs do WAL para que não sejam excluídos antes que o modo de espera os consuma, cada segmento tem 16 MB
hot_standby = on - O parâmetro abaixo ativa a conexão somente leitura no nó quando ele está em função de espera. Isso é ignorado quando o servidor está sendo executado como mestre.

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

# TYPE    DATABASE       USER         ADDRESS        METHOD
host    replication    repl_user    IPaddress(CIDR)    md5

• 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.

pg_basebackup -D <data_directory>  -h <master_host> -X stream -c fast -U repl_user -W

• 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.

standby_mode = ‘on’primary_conninfo  = ‘host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=”host_name”’
recovery_target_timeline = ‘latest’

• 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_standby_names = ‘num_sync ( standby_name [, …] )’

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.