pglogical
, os benefícios e as
limitações dela.
Visão geral
A extensão pglogical
é uma ferramenta de replicação lógica robusta e flexível
projetada para o PostgreSQL. Ela também é compatível com
alta disponibilidade (HA) e recuperação de desastres (DR).
A replicação binária tradicional, conhecida como replicação física, replica as mudanças no sistema de arquivos e no nível de bloco, resultando em um espelho físico no sistema de destino. Embora a replicação física seja robusta e proteja todo o cluster de banco de dados, ela só é unidirecional e exige acesso ao arquivo de dados do banco de dados base e aos arquivos do registro prévio de escrita (WAL, na sigla em inglês).
Já a extensão pglogical
extrai e replica as alterações de SQL de um banco de dados
do provedor e as reproduz em um ou mais bancos de dados
assinantes. Essa replicação é conhecida como replicação lógica.
Com a extensão pglogical
, é possível fazer o seguinte:
- Replicar dados entre vários bancos de dados do AlloyDB Omni.
- Replicar dados entre o AlloyDB Omni e o Google Cloud AlloyDB.
- Replicar dados entre o AlloyDB Omni e outras distribuições do PostgreSQL, incluindo muitos em serviços de nuvem de terceiros.
Benefícios
A replicação lógica com a extensão pglogical
oferece os seguintes benefícios:
Replicação seletiva: oferece a flexibilidade de definir filtros e regras para determinar quais dados replicar e onde. Você pode escolher quais tabelas serão incluídas e como as novas serão processadas, sejam elas incluídas ou não. Também é possível adicionar filtros de coluna e linha. Um
apply delay
opcional pode ser adicionado para situações em que você quer que o assinante represente algum momento final do provedor.Replicação bidirecional e multiprimária: todos os bancos de dados membros estão abertos em um estado de leitura/gravação e são totalmente utilizáveis. Cada banco de dados de endpoint atua como provedor e assinante, permitindo a criação de cenários de replicação avançados e a possibilidade de atualizações de dados feitas em diferentes endpoints.
Suporte de provedores de nuvem: provedores de nuvem como o Google reconhecem o valor da extensão
pglogical
e a integram aos serviços de nuvem, como o Google Cloud SQL para PostgreSQL e o AlloyDB. Outros provedores de nuvem também incluem a extensãopglogical
como opção, permitindo configurações multicloud ou de nuvem híbrida.Replicação entre versões: como o pglogical replica as instruções SQL reais, ele permite a replicação entre versões principais do PostgreSQL. Principalmente quando o banco de dados de origem do provedor é uma versão anterior ao banco de dados de destino do assinante, a replicação entre versões pode ser implementada com confiabilidade.
A extensão
pglogical
oferece suporte a muitas versões anteriores do PostgreSQL como a 9.4 e versões mais recentes. Isso o torna uma opção ideal para cenários em que você está lidando com sistemas legados e quer replicar dados em versões mais modernas do PostgreSQL, como as usadas no AlloyDB Omni e no Google Cloud AlloyDB.
Em resumo, a extensão pglogical
oferece uma solução de replicação lógica
rica em recursos, com compatibilidade para versões mais antigas do PostgreSQL e serviços
gerenciados na nuvem, incluindo o Google Cloud SQL para PostgreSQL e o AlloyDB.
Limitações da replicação lógica
Todas as tecnologias de replicação lógica, incluindo as usadas com outras plataformas de banco de dados relacionais, têm algumas limitações, e qualquer gerenciamento incorreto pode interromper o processo de replicação.
Considere os seguintes pontos para uma implementação confiável:
- Consideração sobre como processar objetos com escopo de banco de dados e de cluster que
estão fora do escopo de replicação. A extensão
pglogical
funciona no nível do banco de dados e apenas em um conjunto especificado de tabelas e sequências. Outros tipos de objetos, como funções e procedimentos, precisam ser replicados usando outro método. - Recomendamos que todas as tabelas de replicação tenham uma chave primária.
É possível usar o recurso de tabela
REPLICA IDENTITY
para informar à extensãopglogical
quais colunas identificam exclusivamente as linhas. Evite fazer isso sempre que possível. Tabelas que não têm chaves primárias são estáticas por natureza e nunca sãoUPDATED
ouDELETED
, além de só oferecer suporte aINSERTS
. Esses tipos de tabelas não precisam de chaves primárias. - Gerenciamento de gatilhos e sequências em bancos de dados assinantes. Por padrão, os gatilhos
são definidos como
ORIGIN
ouLOCAL
e não são disparados no banco de dados assinante quando as linhas são replicadas. Todos os gatilhos precisam ser verificados para garantir que a opçãoREPLICA
esteja definida para qualquer gatilho, de modo que ela não seja disparado no dispositivo assinante, a menos que seja necessário. - Tratamento da resolução de conflitos de forma manual ou automática usando
regras
who wins
. - Replicação de comandos da linguagem de definição de dados (DDL) implementando
manualmente em todos os endpoints ou replicando automaticamente a DDL para bancos de dados assinantes usando
a função de API
pglogical
apropriada no banco de dados do provedor. - Verificação se as tabelas e sequências recém-criadas são adicionadas manual ou automaticamente aos conjuntos de replicação nos bancos de dados primários
- Verificação se uma rede TCP robusta, eficiente, confiável e segura existe entre todos os endpoints na topologia de replicação.
Outras restrições e limitações da extensão pglogical
incluem as
seguintes:
- As permissões de superusuário são necessárias para a versão 2.4.3 do
pglogical
. - Embora a maioria das tabelas e sequências possa ser replicada, outros tipos
de objetos não são replicados pela extensão
pglogical
, e as tabelasTEMPORARY
eUNLOGGED
não são replicadas. - Para replicar a DDL, é necessário usar a função da API pglogical. Os comandos da DDL
nativos não são replicados, exceto o comando
TRUNCATE
. - Opera no nível do objeto por tabela e por sequência e é implantado
por banco de dados. Isso significa que alguns objetos, incluindo objetos
com escopo de cluster, como
users
eroles
, são excluídos da replicação e precisam ser gerenciados separadamente.
A seguir
- Replicar dados entre o AlloyDB para PostgreSQL e o AlloyDB Omni.
- Replicar dados entre o AlloyDB Omni e outros bancos de dados.