Replicar as informações armazenadas em seu banco de dados é essencial para distribuir os dados e garantir que você tenha um backup que possa ser usado para recuperação de desastres, caso algo dê errado.
A replicação do PostgreSQL vem em duas formas, e ambas têm seus usos de nicho. Compreender como aplicar um ou ambos os métodos de replicação de dados pode agilizar seus processos de distribuição de dados. A última coisa que você quer é perder o trabalho crucial que você fez em um banco de dados.
Vamos dar uma olhada nos prós, contras e casos de uso da replicação de streaming e lógica no PostgreSQL.
Definindo a replicação de dados no PostgreSQL
Se você já estiver familiarizado com o que é a replicação de dados, vá em frente e role para baixo até a próxima seção. Mas caso você seja novo na engenharia de banco de dados, queremos estabelecer a base bem rápido.
Como o nome sugere, a replicação é o processo de copiar dados frequentemente de um banco de dados em um servidor de computador para outro banco de dados em um servidor diferente, para que todos os usuários tenham acesso ao mesmo nível de informação. Na computação, a replicação é usada para eliminar falhas em um sistema digital.
A replicação elimina silos de dados, protege informações valiosas e agiliza o desenvolvimento.
No PostgreSQL, existem duas opções para replicação:replicação lógica e por streaming. Esses métodos são ótimos para diferentes casos de uso e, como desenvolvedor, você pode se sentir mais inclinado a usar um em vez do outro. Mas é bom entender como usar os dois para poder decidir qual aplicar em diferentes cenários.
Replicação lógica no PostgreSQL
A replicação de streaming foi introduzida para uso com o PostgreSQL v10.0. A replicação lógica funciona copiando/replicando objetos de dados e suas alterações com base em sua identidade de replicação.
Em muitos casos, a identidade dos dados é uma chave primária. No PostgreSQL, ele oferece aos usuários controle refinado sobre os dados replicados e a segurança das informações.
O termo lógico é usado para distingui-lo da replicação física, que faz uso de replicação byte a byte e endereços de bloco exatos. Leia mais na documentação oficial do PostgreSQL aqui.
Por meio de um modelo de publicação e assinatura, ele funciona permitindo que um ou mais assinantes assinem uma ou mais publicações em um nó publicador. Os assinantes podem extrair informações das publicações e republicar os dados para replicação em cascata ou configuração mais complexa.
A replicação de dados lógicos também pode assumir a forma de replicação transacional. Se o engenheiro quiser copiar uma tabela, ele pode usar esse método de replicação para tirar um instantâneo dos dados do editor e enviá-lo ao banco de dados do assinante.
À medida que os assinantes fazem alterações nos dados originais, o banco de dados do editor recebe atualizações em tempo real. Para garantir a consistência transacional em publicações com uma única assinatura, o assinante deve aplicar os dados na mesma ordem do editor.
Prós da replicação lógica no PostgreSQL
A replicação lógica permite que os usuários empreguem um servidor de destino para gravações e permite que os desenvolvedores tenham diferentes índices e definições de segurança. Isso oferece maior flexibilidade para a transferência de dados entre editores e assinantes.
Suporte entre versões
Além disso, ele vem com suporte a várias versões e pode ser configurado entre diferentes versões do PostgreSQL. Ele também fornece filtragem baseada em eventos. As publicações podem ter várias assinaturas, facilitando o compartilhamento de dados em uma ampla rede.
Carga mínima do servidor
Comparado com as soluções baseadas em trigger, ele possui uma carga mínima de servidor enquanto fornece flexibilidade de armazenamento por meio da replicação de conjuntos menores. Conforme mencionado acima, a replicação lógica de dados pode até copiar dados contidos em tabelas particionadas básicas.
Também é essencial mencionar que a replicação lógica de dados permite a transformação de dados mesmo quando está sendo configurada e permite o streaming paralelo entre os editores.
Contras da replicação lógica no PostgreSQL
A replicação lógica não copiará sequências, objetos grandes, exibições materializadas, tabelas raiz de partição e tabelas externas.
No PostgreSQL, a replicação lógica de dados é suportada apenas por operações DML. Os desenvolvedores não podem usar DDL ou truncar, e o esquema deve ser definido com antecedência. Além disso, ele não suporta replicação mútua (bidirecional).
Se os usuários tiverem conflitos com restrições nos dados replicados em uma tabela, a replicação será interrompida. A única maneira de retomar a replicação é se a causa do conflito for resolvida.
Um conflito não intencional pode interromper o ímpeto de sua equipe, então você precisa entender como resolver qualquer problema rapidamente.
Se o conflito não for resolvido rapidamente, o slot de replicação congelará em sua condição atual, o nó do editor começará a acumular logs de gravação antecipada (WALs) e o nó acabará ficando sem espaço em disco.
Casos de uso para replicação lógica no PostgreSQL
Muitos engenheiros usarão a replicação lógica para:
- Distribuir alterações em um único banco de dados ou subconjunto de banco de dados para assinantes em tempo real
- Mesclar vários bancos de dados em um banco de dados central (geralmente para uso analítico)
- Criando replicações em várias versões do PostgreSQL
- Implantação de replicações entre instâncias do PostgreSQL em diferentes plataformas, como Linux para Windows
- Compartilhando dados replicados com outros usuários ou grupos
- Distribuindo um subconjunto de banco de dados entre vários bancos de dados
Replicação de streaming no PostgreSQL
A replicação de streaming foi introduzida para uso com PostgreSQL 9.0. O processo envia e aplica arquivos Write-Ahead Logging (WAL) de um servidor de banco de dados mestre ou primário para uma réplica ou banco de dados de recebimento. Os WALs são usados para replicação e para garantir a integridade dos dados.
Como funciona a replicação de streaming
A replicação de streaming funciona para preencher a lacuna entre as transferências de dados inerentes ao envio de logs baseado em arquivo, que aguarda até que um WAL atinja a capacidade máxima para enviar dados.
Ao transmitir registros WAL, os servidores de banco de dados transmitem registros WAL em blocos para sincronizar os dados. O servidor em espera se conecta à réplica e recebe os fragmentos WAL à medida que são enviados.
Com a replicação de streaming, o usuário precisa decidir se deseja configurar a replicação assíncrona ou síncrona. Quando a replicação de streaming é implantada inicialmente, o padrão é a replicação assíncrona.
Isso indica que há um atraso entre a alteração inicial no primário e o reflexo dessa alteração na réplica. A assincronização abre a porta para uma possível perda de dados se o mestre travar antes que as alterações sejam copiadas ou se a réplica estiver tão fora de sincronia com o original que já descartou dados pertinentes para fazer alterações.
A replicação síncrona é uma opção muito mais segura porque faz alterações em tempo real. A transferência do mestre para a réplica é considerada incompleta até que ambos os servidores verifiquem as informações. Assim que as alterações de dados forem confirmadas, a transferência é registrada nos WALs de ambos os servidores.
Quer você use a replicação assíncrona ou síncrona, as réplicas devem ser conectadas ao mestre por meio de uma conexão de rede. Além disso, é essencial que os usuários configurem privilégios de acesso aos fluxos WAL da réplica, para que as informações não sejam comprometidas.
Prós da replicação de streaming no PostgreSQL
Uma das vantagens mais significativas de usar a replicação de streaming é que a única maneira de perder dados é se os servidores primário e de recebimento falharem ao mesmo tempo. Se você estiver entregando informações importantes, a replicação de streaming garante que uma cópia do seu trabalho seja salva.
Os usuários podem conectar mais de um servidor standby ao primário e os logs serão transmitidos do primário para cada um dos standbys conectados. Se uma das réplicas atrasar ou for desconectada, o streaming continuará para as outras réplicas.
Configurar o envio de logs por meio da replicação de streaming não interferirá em nada que o usuário esteja executando no banco de dados primário. Se o servidor de dados primário precisar ser desligado, ele aguardará até que os registros atualizados sejam enviados à réplica antes de desligar.
Contras da replicação de streaming no PostgreSQL
A replicação de streaming não copia informações para uma versão ou arquitetura diferente, altera as informações dos servidores em espera e não oferece replicação granular.
Especialmente com a replicação de dados de streaming assíncrona, os arquivos WAL mais antigos que ainda não são copiados para a réplica podem ser reciclados quando o usuário faz alterações no mestre. Para garantir que os arquivos vitais não sejam perdidos, o usuário pode definir o wal_keep_segments para um valor mais alto.
Sem as credenciais de autenticação do usuário configuradas para os servidores de réplica, pode ser fácil extrair dados confidenciais. Para que ocorram atualizações em tempo real entre o mestre e a réplica, o usuário precisa alterar o método de replicação da replicação assíncrona padrão para a replicação síncrona.
Casos de uso para replicação de streaming no PostgreSQL
Muitos engenheiros usarão a replicação de streaming para:
- Criando um backup para o banco de dados principal em caso de falha do servidor ou perda de dados
- Promover uma solução de alta disponibilidade com o menor atraso de replicação possível
- Descarregar grandes consultas para aliviar um pouco o estresse no sistema principal
- Distribuindo cargas de trabalho de banco de dados em várias máquinas, especialmente para formatos somente leitura
O que está reservado para o futuro?
O PostgreSQL Global Development Group anunciou o lançamento do PostgreSQL 14 em 30 de setembro de 2021. A nova versão veio carregada com atualizações tanto em streaming quanto em replicações lógicas por meio da plataforma.
Para replicação de streaming, a versão 14 permite que os usuários:
- Defina o parâmetro do servidor
log_recovery_conflict_waitspara relatar automaticamente longos tempos de espera de conflito de recuperação - Pausar a recuperação em um servidor de espera ativa ao alterar os parâmetros em um servidor primário (em vez de desligar o modo de espera imediatamente)
- Usar a função
pg_get_wal_replay_pause_state()para relatar o estado de recuperação com mais detalhes - Forneça um parâmetro de servidor somente leitura
in_hot_standby - Trunque rapidamente tabelas pequenas durante a recuperação em clusters que têm um grande número de buffers compartilhados
- Permitir a sincronização do sistema de arquivos no início da recuperação de falhas por meio do Linux
- Usar a função
pg_xact_commit_timestamp_origin()em uma transação especificada para retornar o carimbo de data/hora do commit e a origem da replicação - Usar a função
pg_last_committed_xact()para adicionar a origem de replicação no registro retornado - Empregar controles de permissão de função padrão para alterar as funções de origem de replicação (o padrão ainda limita o acesso aos superusuários)
Para replicação lógica, a versão 14 permite que os usuários:
- Transmita transações longas em andamento para assinantes com a API de replicação lógica
- Permitir várias transações durante as replicações de tabela
- Gere subtransações imediatas de log WAL e associações XID de nível superior
- Usar a função
pg_create_logical_replication_slot()para aprimorar APIs de decodificação lógica para commits de duas fases - Adicione mensagens de invalidação de cache ao WAL durante a conclusão do comando para permitir o streaming lógico de transações em andamento
- Controle quais mensagens de decodificação lógica são enviadas ao fluxo de replicação
- Use o modo de transferência binária para replicações mais rápidas
- Filtrar decodificação por XID
O PostgreSQL já está trabalhando para a versão 15, que deve ser lançada no terceiro trimestre de 2022. Um dos problemas de replicação a serem resolvidos na versão mais recente é impedir o uso de variáveis herdadas do ambiente do servidor na replicação de streaming. Mas à medida que mais usuários se adaptam à versão 14, o PostgreSQL provavelmente adicionará mais tarefas para melhorar as funções de replicação.
Uma rápida comparação de replicação do PostgreSQL:replicação lógica vs. de streaming
| Replicação lógica | Replicação de streaming | |
|---|---|---|
| Modelo | Editor para assinante | Mestre para réplica |
| Replicação Transacional | Sim | Não |
| Lacunas na replicação | Um conflito interromperá a replicação | Assíncrono – pode causar um atraso entre a transferência de dados entre o primário e a réplica; síncrono – os dados só são perdidos se todos os servidores conectados travarem simultaneamente |
| Replicação em diferentes plataformas ou versões do PostgreSQL | Sim | Não |
| Segurança | O acesso aos dados é limitado aos assinantes | Deve configurar credenciais de acesso para manter os dados seguros |
| Tamanho das replicações | Melhor para replicações granulares | Melhor para replicações em grande escala |
| Especialmente útil para | Mesclando vários sistemas em um banco de dados | Criando um banco de dados de backup |
Conclusão
Esperamos que este guia seja útil ao configurar suas funções de replicação. Se você tiver alguma dúvida ou quiser saber mais sobre como o ScaleGrid pode ajudá-lo com suas implantações do PostgreSQL, entre em contato com um de nossos muitos especialistas em banco de dados.
|
