Usando a replicação lógica do PostgreSQL para manter um servidor de teste de leitura/gravação sempre atualizado

Introdução

Tipos de replicação e histórico de replicação do PostgreSQL

• Replicação física (binária)
  • Nível do sistema operacional (replicação do vSphere)
  • Nível do sistema de arquivos (DRBD)
  • Nível do banco de dados (baseado em WAL)
• Replicação lógica (nível de banco de dados)
  • Baseado em gatilho (DBMirror, Slony)
  • Middleware (pgpool)
  • baseado em WAL (pglogical, replicação lógica)

• 2001:DBMirror (baseado em gatilho)
• 2004:Slony1 (baseado em gatilho), pgpool (middleware)
• 2005:PITR (baseado em WAL) introduzido no PostgreSQL 8.0
• 2006:espera a quente no PostgreSQL 8.2
• 2010:replicação de streaming físico, espera ativa no PostgreSQL 9.0
• 2011:replicação de streaming síncrona no PostgreSQL 9.1
• 2012:replicação de streaming em cascata no PostgreSQL 9.2
• 2013:trabalhadores em segundo plano no PostgreSQL 9.3
• 2014:API de decodificação lógica, slots de replicação. (Os fundamentos da Replicação Lógica) no PostgreSQL 9.4
• 2015:2ndQuadrant apresenta pglogical, o ancestral ou replicação lógica
• 2017:replicação lógica no núcleo do PostgreSQL 10!

Conceitos básicos de replicação lógica do PostgreSQL

• Publicação: Um conjunto de alterações de um conjunto de tabelas definidas em um banco de dados específico em um servidor primário de replicação física. Uma publicação pode lidar com todos ou alguns de:INSERT, DELETE, UPDATE, TRUNCATE.
• Nó do editor: O servidor onde a publicação reside.
• Identidade da réplica: Uma maneira de identificar a linha no lado do assinante para UPDATEs e DELETEs.
• Assinatura: Uma conexão com um nó de editor e uma ou mais publicações nele. Uma assinatura usa um slot de replicação dedicado no editor para replicação. Slots de replicação adicionais podem ser usados ​​para a etapa de sincronização inicial.
• Nó do assinante: O servidor onde reside a assinatura.

• Tirar um instantâneo da tabela no editor e copiá-lo para o assinante
• Aplicando todas as alterações (desde o instantâneo) na mesma sequência

• Banco de dados único ou replicação específica de tabela (sem necessidade de replicar todo o cluster)
• Configurar acionadores para o assinante para uma tarefa específica (como anonimização, que é um tópico muito importante após a entrada em vigor do GDPR)
• Fazer com que um nó de assinante colete dados de muitos nós de editor, permitindo assim o processamento analítico central
• Replicação entre diferentes versões/arquiteturas/plataformas (zero upgrades de tempo de inatividade)
• Usando o nó do assinante como servidor de banco de dados para um ambiente de teste/desenvolvimento. Por que queremos isso é porque testar com dados reais é o tipo de teste mais realista.

Ressalvas e Restrições

Restrições

• Apenas operações DML são suportadas. Sem DDL. O esquema deve ser definido antecipadamente
• As sequências não são replicadas
• Objetos grandes não são replicados
• Apenas tabelas base simples são suportadas (visualizações materializadas, tabelas raiz de partição, tabelas estrangeiras não são suportadas)

Advertências

1. Resolva o problema real
2. Ignore a transação com falha chamando pg_replication_origin_advance

Configurando os nós do editor e do assinante

• Lado do editor
  • wal_level>=“lógico”
  • max_replication_slots>=#subscriptions + sincronização inicial da tabela
  • max_wal_senders>=max_replication_slots + other_physical_standbys
• Lado do assinante
  • max_replication_slots>=#subscriptions
  • max_logical_replication_workers>=#subscriptions + sincronização inicial da tabela
  • max_worker_processes>=max_logical_replication_workers + 1 + max_parallel_workers

• Execute um novo initdb no nó do assinante
• Descarregue o esquema do cluster do editor e copie para o nó do assinante
• Crie o esquema no assinante
• Decida quais tabelas você precisa e quais não precisa.

• É uma tabela fictícia sem importância (e talvez você deva retirá-la da produção também)
• é uma tabela local para o ambiente de produção, o que significa que faz todo o sentido que a mesma tabela no ambiente de teste (assinante) tenha seus próprios dados

• Encontre as tabelas sem candidato óbvio para REPLICA IDENTITY

  select table_schema||'.'||table_name from information_schema.tables where table_type='BASE TABLE' AND table_schema||'.'||table_name NOT IN (select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type in ('PRIMARY KEY','UNIQUE')) AND table_schema NOT IN ('information_schema','pg_catalog') ;

• Encontre as tabelas sem PRIMARY KEY mas com um UNIQUE INDEX

  select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type = 'UNIQUE' EXCEPT select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type = 'PRIMARY KEY';

• Percorra as listas acima e decida o que fazer com cada tabela
• Crie a publicação com as tabelas para as quais existe um PK

  select 'CREATE PUBLICATION data_for_testdb_pub FOR TABLE ONLY ' || string_agg(qry.tblname,', ONLY ') FROM (select table_schema||'.'||quote_ident(table_name) as tblname from information_schema.tables where table_type='BASE TABLE' AND table_schema||'.'||table_name IN (select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type in ('PRIMARY KEY')) AND table_schema NOT IN( 'information_schema','pg_catalog')  ORDER BY 1) as qry;
  \gexec

• Em seguida, crie a assinatura no nó do assinante

  create subscription data_for_testdb_pub CONNECTION 'dbname=yourdb host=yourdbhost user=repmgr' PUBLICATION data_for_testdb_pub ;

  O acima também copiará os dados.
• Adicione as tabelas que você deseja que tenham um índice UNIQUE
  Execute tanto em nós de editor quanto de assinante, por exemplo:

  ALTER TABLE someschema.yourtable REPLICA IDENTITY USING INDEX yourindex_ukey;

  No editor:

  ALTER PUBLICATION data_for_testdb_pub ADD TABLE ONLY someschema.yourtable;

  No assinante:

  ALTER SUBSCRIPTION data_for_testdb_pub REFRESH PUBLICATION WITH ( COPY_DATA );

• Neste ponto (sincronização), você deve sempre ficar de olho no log do PostgreSQL no nó do assinante. Você não quer nenhum erro ou qualquer coisa (timeout) que proíba a continuação da replicação lógica. SOLVE QUALQUER ERRO IMEDIATAMENTE , ou o editor continuará acumulando arquivos WAL em pg_wal e, eventualmente, ficará sem espaço. Então você tem que lidar com
  • Todos os ERROS ou qualquer mensagem sobre o trabalhador lógico que resulte na saída
  • Cuide também de
    • wal_receiver_timeout
    • wal_sender_timeout

1. Anonimização
2. Chaves primárias e chaves exclusivas baseadas em violações de sequências
3. Um conjunto geral de boas práticas
4. Monitoramento

Anonimização

Chaves primárias com sequências

• Na tarde de sexta você faz alguns testes no banco de dados do assinante inserindo uma nova linha em alguma tabela. Isso terá como ID o próximo valor gerado pela sequência.
• Você vai para casa no fim de semana.
• Algum usuário de produção insere uma linha na mesma tabela no banco de dados do editor.
• A linha será replicada com base na REPLICA IDENTITY para o nó do assinante, mas falhará devido ao ERRO de violação de PK. O trabalhador lógico em segundo plano sairá e tentará novamente. Mas continuará falhando enquanto o problema persistir.
• A replicação ficará travada. O slot de replicação começará a acumular WALs.
• O editor fica sem espaço em disco.
• No fim de semana, você recebe um e-mail informando que seu nó principal entrou em PÂNICO!

select 'SELECT setval(''' || seqrelid::regclass||''','||CASE WHEN seqincrement <0 THEN -214748364 ELSE 214748364 END||');' from pg_sequence where seqtypid=20;
\gexec

Um conjunto de boas práticas

Monitoramento

• TODAS as mensagens no log do assinante que são relevantes para a saída lógica do trabalhador. Instalar uma ferramenta como tail_n_mail pode realmente ajudar com isso. Uma configuração que funciona:

  INCLUDE: ERROR:  .*publisher.*
  INCLUDE: ERROR:  .*exited with exit.*
  INCLUDE: LOG:  .*exited with exit.*
  INCLUDE: FATAL:  
  INCLUDE: PANIC:

  Assim que recebermos um alerta vindo do tail_n_mail, devemos resolver o problema imediatamente.
• pg_stat_subscription. Pid não deve ser nulo. Além disso, o atraso deve ser pequeno.

• pg_stat_replication. Isso deve ter quantas linhas forem necessárias:uma para cada espera de replicação de streaming conectada (nós de assinante e outras esperas físicas incluídas).
• pg_replication_slots para o espaço do assinante. Isso deve estar ativo.