pgactive - extensão de replicação active-active para Postgres

• Extensão de replicação active-active para PostgreSQL criada e publicada pela AWS
• Quando é necessário gravar e modificar dados em várias instâncias do PostgreSQL, em vez do modelo tradicional active-standby, no qual uma instância específica aceita sozinha as alterações, é possível construir uma estrutura que permite alterações simultâneas e replicação em várias instâncias
• É adequada para cenários como configuração de banco de dados de alta disponibilidade em várias regiões, minimização da latência de escrita, atualizações blue/green da aplicação e migração bidirecional de dados
• Com uso de replicação lógica, oferece suporte a detecção de conflitos, resolução de conflitos de escrita e conversão de formato do banco de dados de destino

Conceito de replicação active-active

• Replicação (Replication) é a tecnologia de sincronizar alterações entre bancos de dados
• A estrutura tradicional active-standby do PostgreSQL aceita alterações em apenas uma instância, enquanto as demais ficam somente para leitura, de modo que um único local atua como fonte dos dados
• O pgactive fornece uma topologia de replicação active-active, permitindo gravação de dados simultaneamente em várias instâncias
• Essa abordagem é adequada para ambientes que exigem vários pontos de escrita, como implantações multi-região ou migração bidirecional
• No modelo active-active, é necessário gerenciamento adicional para conflitos, latência e algumas limitações funcionais

Tecnologia principal: replicação lógica

• Replicação lógica (Logical Replication) transmite os dados em um formato que sistemas externos conseguem interpretar
• Por meio da replicação lógica, é possível implementar diversos recursos adicionais no banco de dados de destino, como detecção de conflitos, resolução de conflitos de escrita e transformação de consultas
• O PostgreSQL introduziu a replicação lógica básica na versão 10, em 2017, mas a replicação active-active exige funcionalidades adicionais
• Devido às características de projeto do PostgreSQL, essas funcionalidades podem ser desenvolvidas e aplicadas na forma de extensão (extension)
• A comunidade de desenvolvimento do PostgreSQL também vem adicionando gradualmente esses recursos ao projeto principal

[GN⁺]

Comentários do Hacker News

• Organizei a história da evolução do BDR, pglogical, pgactive e Postgres Distributed (PGD) com base no que ouvi de colegas das equipes da 2nd Quadrant e da EDB
  O primeiro a surgir, e que continua open source até hoje, foi o BDR1 (link), e o pgactive é baseado nele
  O BDR2 foi uma reescrita closed source do BDR1 e acabou sendo descontinuado
  Foram lançados o pglogical v1 e v2 (ambos open source, link), e o v1 foi amplamente modificado e incorporado ao Postgres 10
  Com base na experiência com a funcionalidade de replicação lógica do Postgres 10, a 2nd Quadrant começou o desenvolvimento do pglogical v2, do qual também surgiu o pgEdge
  Depois, a 2nd Quadrant criou as versões closed source pglogical v3 e BDR v3, e uniu os dois no BDR v4
  Em seguida, o nome do produto BDR foi alterado para Postgres Distributed (PGD, link)
  Após a aquisição da 2ndQuadrant pela EDB, a EDB lançou o PGD v6
  • A PostgresPro também tem um sistema separado de replicação multi-master link da documentação
  • Pergunta se o PGDv6 ainda é closed source
• Este sistema usa a replicação lógica do Postgres para transmitir alterações de uma instância para outra
  Quando ocorre um conflito, o valor gravado por último com base no timestamp é o que acaba sendo aplicado
  O histórico dos conflitos fica registrado em uma tabela especial chamada pgactive_conflict_history, então é possível analisar o histórico e fazer resolução manual
  Veja aqui para mais detalhes e documentação
  • Pergunta se isso se enquadra como replicação multi-master
    Se essa funcionalidade pudesse ser oficialmente incorporada ao Postgres, seria interessante
  • Do ponto de vista do usuário, gostaria de saber se a própria escrita é aprovada imediatamente ou se no fim tudo apenas converge
• Pergunta se alguém usou recentemente, na prática, o banco de dados da Bloomberg (comdb2)
• Em um assunto relacionado, mas um pouco diferente, pergunta se existe alguma forma de fazer uma "replicação com escrita local possível (baseada em read replica)"
  Por exemplo, gostaria de usar um banco de dados secundário que lê dados de produção ou staging, mas que só possa ser modificado localmente e cujos resultados não sejam refletidos de volta no upstream
  Hoje, na maioria dos casos, isso é feito criando snapshots periodicamente com scripts (cron etc.) por meio de dumps de dados ou consultas, armazenando-os no S3 e depois baixando e restaurando os dados localmente
  Esse método costuma funcionar bem na maior parte do tempo, mas às vezes a construção de índices demora demais
  • Como referência, isso pode ser arriscado quando dados sensíveis, como informações pessoais, acabam entrando diretamente em ambientes de staging ou dev
    Como as implicações legais e éticas são grandes, a maioria das empresas não recomenda essa abordagem
  • Se usar a replicação lógica do Postgres com filtros, dá para fazer replicação unidirecional, e basta remover o slot de replicação para poder alterar livremente os dados localmente
    Assim, é possível modificar apenas as tabelas locais sem afetar o primário
  • Manter um banco de dados local "puro" como base e cloná-lo sempre que necessário para usá-lo como banco de desenvolvimento permite cópias muito rápidas, sem reconstruir índices
    Recomenda o comando createdb --template
  • Pergunta como lidar com conflitos entre escritas locais e atualizações remotas
    Não consegue imaginar uma estratégia de merge que sirva para todas as situações
  • Pelo que sei, em uma configuração de replicação lógica do Postgres esse é o comportamento padrão
    O replica não é impedido de receber escritas; apenas acontece que o resultado não se propaga para outros lugares
• É sempre importante lembrar que o termo "Conflict resolution" no fim significa "quebrar a durabilidade ao descartar dados que já foram commitados e aprovados"
  O ideal é projetar a arquitetura de modo que não haja sobreposição das áreas de dados graváveis entre todas as instâncias ativas
  Nesses casos, ferramentas como o pgactive podem ser úteis
  Ou então faz mais sentido usar desde o início um banco de dados distribuído, como o Yugabyte
  • A própria documentação oficial recomenda, como forma de evitar conflitos, dividir os schemas por master para que "cada master seja o único writer de cada schema"
    Todos os masters leem todos os schemas, mas cada um escreve apenas no que lhe cabe
    Pergunta se, em vez de schema, também daria para distribuir a responsabilidade usando particionamento etc.
• Isso leva a pensar por que a AWS criou isso
  Não vem à mente nenhum uso direto desse recurso nos próprios produtos da empresa
  O RDS usa block replication, e o Aurora usa sua replicação SAN própria
  Supõe que talvez a intenção seja usar isso em algo como o DMS
  • Talvez seja por causa do Aurora DSQL lançado recentemente
  • Na verdade, não vê muita utilidade prática nisso
    Questiona por que alguém faria isso em um banco relacional fortemente ACID
  • Pelo que sabe, a replicação SAN do Aurora não é usada para replicação entre regiões
  • O readme do repositório também deixa claro que o "principal caso de uso é construir clusters de banco de dados de alta disponibilidade multi-região"
  • Dizem que esse recurso já era oferecido no RDS Postgres havia 2 anos (link relacionado)
    Mas houve notícia de que, há 1 mês, ele foi oficialmente aberto como open source para a comunidade (anúncio oficial)
• Já operou vários clusters com repmgr e patroni em ambiente realmente sem downtime, e preferiria instalar esse plugin só como último recurso
  Para conseguir dormir bem à noite, preferiria evitar ao máximo
• Por coincidência, recentemente estava procurando uma forma simples de montar um cluster Postgres altamente disponível com "failover automático, recuperação de nó e recuperação pontual"
  A combinação patroni+etcd+haproxy é muito recomendada, e ver pessoas que já usaram falando com tanto entusiasmo sugere que deve haver um bom motivo
  Mas, ao olhar arquivos de exemplo com docker compose, pareceu um pouco intimidador
  O pgpool parece mais simples, já que bastaria colocá-lo na frente de cada postgres
  Gostaria de ouvir recomendações ou experiências de quem realmente gosta de Postgres no dia a dia
  O objetivo é montar, com docker compose e da forma mais simples possível, um cluster com alta disponibilidade, perda mínima ou nenhuma perda, e recuperação pontual
  • Pergunta se o que está procurando é algo como o Barman
  • Está usando cloudnativepg, e com ele a maior parte do que precisa já funciona de imediato
• Compartilha outros materiais sobre pgactive e casos relacionados, caso ajudem
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  Post do Hacker News (post de outubro de 2023, com 1 comentário)
• Parece ser assíncrono, e deve haver questões importantes envolvendo isolamento de transações
  • No fim, a posição é que tudo se resume a trade-offs
    Ou seja, cada caso precisa aceitar vantagens e desvantagens conforme a situação