Como otimizar a replicação lógica do PostgreSQL

Replicação lógica ou Pglogical é um mecanismo de replicação baseado em WAL em nível de tabela que replica os dados de tabelas específicas entre duas instâncias do PostgreSQL. Parece haver uma confusão entre “pglogical” e “Logical Replication”. Ambos fornecem o mesmo tipo de mecanismo de replicação com algumas diferenças em recursos e capacidades. A Replicação Lógica é introduzida no PostgreSQL-10 como um recurso embutido, diferentemente do pglogical, que é uma extensão. “Pglogical” com desenvolvimentos contínuos em andamento, permanece como a única opção para implementar a Replicação Lógica para esses ambientes usando versões do PostgreSQL anteriores a 10. Eventualmente, todos os recursos que fazem parte do pglogical farão parte da Replicação Lógica. Em outras palavras, pglogical (extensão) tornou-se Logical Replication (recurso embutido). A vantagem básica da Replicação Lógica é que ela não precisa de nenhuma extensão para ser instalada/criada, o que por sua vez é benéfico para aqueles ambientes onde a instalação de extensões é restrita.

Este blog se concentrará na otimização da replicação lógica. Isso significa que as dicas e técnicas de otimização destacadas neste blog se aplicarão tanto ao pglogical quanto ao Logical Replication.

A replicação lógica é uma replicação baseada em WAL que é a primeira de seu tipo. Como um DBA, isso seria um mecanismo de replicação muito mais confiável e de alto desempenho quando comparado a outras soluções de replicação baseadas em gatilho. As alterações feitas nas tabelas que fazem parte da replicação do pglogical são replicadas em tempo real via registros WAL, o que o torna altamente eficiente e não complexo. Todos os outros mecanismos de replicação no mercado são baseados em gatilhos, o que pode representar desafios de desempenho e manutenção. Com a chegada da Replicação Lógica, a dependência da replicação baseada em gatilho está quase acabando.

Existem outros blogs que explicam detalhadamente como configurar a Replicação Lógica.

Neste blog, o foco será em como otimizar a replicação lógica.

Otimização da replicação lógica

Para começar, o comportamento da “Replicação Lógica” é bastante semelhante ao da “Replicação de Streaming”, a única diferença é que a replicação de streaming replica o banco de dados completo enquanto a Replicação Lógica replica apenas tabelas individuais. Ao escolher tabelas individuais específicas para replicar, existem fatores/desafios a serem previstos.

Vamos dar uma olhada nos fatores que influenciam a replicação lógica.

Fatores que influenciam o desempenho da replicação lógica

A otimização da replicação lógica é importante para garantir que os dados sejam replicados perfeitamente, sem interrupções. Há fatores a serem previstos antes de configurá-lo. Vamos dar uma olhada neles:

O tipo de dados armazenados nas tabelas a serem replicados
Quão ativas transacionalmente são as tabelas (parte da replicação)
A capacidade da infraestrutura deve ser prevista
A configuração dos parâmetros deve ser feita de forma otimizada

Todos os fatores acima influenciam a Replicação Lógica em maior medida. Vamos dar uma olhada neles em detalhes.

Tipos de dados de replicação lógica do PostgreSQL

Compreender o tipo de dados armazenados na tabela é importante. Se a parte da replicação da tabela armazenar texto grande ou objetos binários e encontrar um grande número de transações, a replicação poderá ficar lenta devido ao alto uso de recursos de infraestrutura. A capacidade da infraestrutura deve ser adequada para lidar com replicação de dados tão complexa e de grande porte.

Como as tabelas ativas são parte transacional da replicação

Ao replicar tabelas altamente transacionalmente ativas, a Replicação pode ficar para trás na sincronização devido a problemas de desempenho de E/S, deadlocks, etc., que precisam ser levados em consideração. Isso pode não tornar os ambientes de banco de dados de produção mais saudáveis. Se o número de tabelas que estão sendo replicadas for alto e os dados forem replicados para vários sites, pode haver alto uso de CPU e mais número de CPUs (ou núcleos de CPU) são necessários.

Capacidade de infraestrutura

Antes de considerar a Replicação Lógica como uma solução, é importante garantir que a capacidade da Infraestrutura dos servidores de banco de dados seja adequada o suficiente. Se houver um grande número de tabelas sendo replicadas, deve haver CPUs suficientes disponíveis para fazer o trabalho de replicação.

Ao replicar um grande número de tabelas, considere dividi-las em grupos e replicar em paralelo. Novamente, isso precisará que várias CPUs estejam disponíveis para replicação. Se as alterações de dados nas tabelas que estão sendo replicadas forem frequentes e altas, isso também poderá afetar o desempenho da replicação.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper

Otimização de parâmetros para replicação lógica

Os parâmetros configurados para o funcionamento da Replicação Lógica devem ser ajustados de maneira ideal para garantir que a replicação não seja interrompida.

Vamos primeiro dar uma olhada nos parâmetros necessários para configurá-lo:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Ajustando max_wal_senders

max_wal_senders deve ser sempre maior que o número de réplicas. Se os dados forem replicados para vários sites, vários max_wal_senders entrarão em ação. Portanto, é importante garantir que esse parâmetro seja definido com um número ideal.

Ajustando max_replication_slots

Em geral, todas as alterações de dados que ocorrem nas tabelas são gravadas em arquivos WAL em pg_xlog / pg_wal que são denominados como registros WAL. O processo do remetente Wal pegaria esses registros WAL (pertencentes às tabelas que estão sendo replicadas) e enviaria para as réplicas e o processo wal_receiver no site da réplica aplicaria essas alterações no nó do assinante.

Os arquivos WAL são removidos do local pg_xlog/pg_wal sempre que ocorrer um ponto de verificação. Se os arquivos WAL forem removidos antes mesmo que as alterações sejam aplicadas ao nó do assinante, a replicação será interrompida e ficará para trás. Caso o nó do assinante fique para trás, um slot de replicação garantiria que todos os arquivos WAL necessários para o assinante entrar em sincronia com o provedor fossem retidos. Recomenda-se configurar um slot de replicação para cada nó do assinante.

Ajustando max_worker_processes

É importante ter um número ideal de processadores de trabalho configurados. Isso depende do número máximo de processos que um servidor pode ter. Isso só é possível em ambientes com várias CPUs. Max_worker_processes garantirá que vários processos sejam gerados para realizar o trabalho de maneira mais rápida, utilizando vários núcleos de CPU. Ao replicar dados usando a Replicação Lógica, esse parâmetro pode ajudar a gerar vários processos de trabalho para replicar os dados mais rapidamente. Existe um parâmetro específico chamado max_logical_worker_processes que garantirá que vários processos sejam usados para copiar os dados.

Ajustando max_logical_worker_processes

Este parâmetro especifica o número máximo de processos de trabalho lógicos necessários para executar a replicação e sincronização de dados de tabela. Este valor é obtido de max_worker_processes que deve ser maior que este valor de parâmetro. Esse parâmetro é muito benéfico ao replicar dados para vários sites em ambientes com várias CPUs. O padrão é 4. O valor máximo depende de quantos processos de trabalho o sistema suporta.

Ajustando max_sync_workers_per_subscription

Este parâmetro especifica o número máximo de processos de sincronização necessários por assinatura. O processo de sincronização ocorre durante a sincronização inicial de dados e, para garantir que isso aconteça mais rapidamente, esse parâmetro pode ser usado. Atualmente, apenas um processo de sincronização pode ser configurado por tabela, o que significa que várias tabelas podem ser sincronizadas inicialmente em paralelo. O valor padrão é 2. Esse valor é selecionado do valor max_logical_worker_processes.

Esses são os parâmetros que devem ser ajustados para garantir que a Replicação Lógica seja eficiente e rápida. Os outros parâmetros que também afetam a replicação lógica são os seguintes.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Esses parâmetros não têm nenhum efeito no nó do provedor.

Conclusão

Tabelas específicas de replicação são um requisito comum que surge em sistemas de banco de dados grandes e complexos. Isso pode ser para relatórios de negócios ou fins de armazenamento de dados. Como DBA, acredito que a Replicação Lógica atende muito a esses propósitos devido à sua fácil implementação com menos complexidade. Configurar e ajustar a replicação lógica requer uma boa quantidade de planejamento, arquitetura e teste. A quantidade de dados que estão sendo replicados em tempo real deve ser avaliada para garantir que um sistema de replicação eficiente e sem aparência esteja em vigor. Para concluir, Bancos de Dados rodando em PostgreSQL-10, Replicação Lógica é o caminho a seguir e para aqueles bancos de dados rodando em PostgreSQL versões <10, pglogical é a opção.