Replicação Lógica no PostgreSQL 10
•
3 gostaram•2,107 visualizações
Este documento apresenta sobre replicação lógica no PostgreSQL 10, incluindo sua arquitetura, configuração e funcionamento. A replicação lógica replica mudanças de dados de um banco de dados publicador para bancos de dados assinantes de forma assíncrona e transacional através de publicações e assinaturas.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Replicação Lógica no PostgreSQL 10
Semelhante a Replicação Lógica no PostgreSQL 10 (20)
Replicação Lógica no PostgreSQL 10
- 1. Replicação Lógica no PostgreSQL 10 Euler Taveira 12/07/2017
- 2. Sobre esta apresentação • esta apresentação está sob licença Creative Commons Atribuição-Não Comercial 3.0 Brasil: http://creativecommons.org/licenses/by-nc/3.0/br c b n
- 3. Resumo 1 Introdução 2 Arquitetura 3 Replicação Lógica 4 Configuração 5 Limitações 6 Conclusão Timbira - A empresa brasileira de PostgreSQL 1 / 44
- 4. Replicação Lógica nó A nó B Timbira - A empresa brasileira de PostgreSQL 2 / 44
- 5. Histórico • RServ • Slony-I • Londiste • Bucardo • pgpool-II • BDR • pglogical Timbira - A empresa brasileira de PostgreSQL 3 / 44
- 6. Evolução • 9.0 • protocolo de replicação • 9.2 • cascateamento • 9.3 • gatilhos de eventos • background workers • 9.4 • slots de replicação • logical decoding • 9.5 • replication origins • 10.0 • replicação lógica • facilitar configuração de replicação (parâmetros padrão) Timbira - A empresa brasileira de PostgreSQL 4 / 44
- 7. Replicação Lógica • replica mudanças • INSERT, UPDATE e DELETE • modelo publish-subscribe • replicação transacional • subscriber aplica dados na mesma ordem que no publisher • sincronismo inicial • cascateamento Timbira - A empresa brasileira de PostgreSQL 5 / 44
- 8. Replicação Lógica: Vantagens • não utiliza gatilhos • reduz carga de escrita no publisher • subscriber não está em modo standby • uso de tabelas temporárias no subscriber • não precisa cancelar consultas para replicação continuar • nós podem ter diferentes roles, permissões e parâmetros • replica um banco de dados ou um conjunto de tabelas • replica para diferentes versões do PostgreSQL • replica para diferentes sistemas operacionais • múltiplos publisher para um subscriber • consolidação de dados Timbira - A empresa brasileira de PostgreSQL 6 / 44
- 9. Replicação Lógica: Casos de Uso • replicação seletiva • um banco de dados • parte de um banco de dados • atualização entre versões do PostgreSQL • consolidação de múltiplos bancos de dados • distribuição de dados Timbira - A empresa brasileira de PostgreSQL 7 / 44
- 10. Comparativo RL BDR HS Slony Bucardo Multi-master não sim não não sim Por Banco sim sim não sim sim Cascateamento sim não sim sim - DDL não sim sim não ⋆ não Daemon externo não não não sim sim Novas Tabelas Adicionadas não sim sim não não Sequências Transparentes não sim - - não Usa gatilhos / Escrita 2x não não não sim sim UPDATE na PK sim sim sim não não Replicação Seletiva sim sim não sim sim Aplica Txn Individual sim sim sim não não extraído do site do BDR Timbira - A empresa brasileira de PostgreSQL 8 / 44
- 11. Resumo 1 Introdução 2 Arquitetura 3 Replicação Lógica 4 Configuração 5 Limitações 6 Conclusão Timbira - A empresa brasileira de PostgreSQL 9 / 44
- 12. Arquitetura • logical replication worker estabelece uma conexão (via libpq) com servidor publisher • servidor publisher abre o processo walsender para enviar mudanças ao servidor subscriber • cada subscription habilitada terá uma processo walsender correspondente no servidor publisher • replicação síncrona somente com interface do protocolo buffers wal publisher subscriber postgres postgres conexão wal sender output plugin mudanças logical replication worker Timbira - A empresa brasileira de PostgreSQL 10 / 44
- 13. Decodificação Lógica • envia modificações feitas para consumidores externos • mudanças são enviadas através de slots de replicação • casos de uso • sistemas de replicação • auditoria • formato é determinado pelo output plugin • plugins podem ser escritos para fornecer formatos adicionais • test_decoding • wal2json • plugin utilizado para replicação lógica é o pgoutput Timbira - A empresa brasileira de PostgreSQL 11 / 44
- 14. Slots de Replicação • envia mudanças para cliente na mesma ordem da origem • cada slot envia uma sequência de mudanças de um banco de dados • slot tem um identificador único para todo cluster • não depende de conexão (persistentes) • a prova de falha (crash-safe) • um cliente consome mudanças de um slot por vez • slots não sabem o estado dos seus consumidores Timbira - A empresa brasileira de PostgreSQL 12 / 44
- 15. Interface do Protocolo • somente utilizando conexão de replicação (replication=1) • pg_recvlogical • comandos • CREATE_REPLICATION_SLOT foo LOGICAL wal2json • START_REPLICATION SLOT foo LOGICAL XXX/XXX (opt1 value1, opt2 value2) • DROP_REPLICATION_SLOT foo Timbira - A empresa brasileira de PostgreSQL 13 / 44
- 16. Interface SQL • pg_create_logical_replication_slot(’foo’, ’wal2json’) • pg_logical_slot_get_changes(’foo’, NULL, NULL, ’opt1’, ’value1’, ’opt2’, ’value2’) • pg_logical_slot_peek_changes(’foo’, NULL, NULL, ’opt1’, ’value1’, ’opt2’, ’value2’) • pg_drop_replication_slot(’foo’) Timbira - A empresa brasileira de PostgreSQL 14 / 44
- 17. Background Workers • PostgreSQL executa código do usuário • processos são iniciados, parados e monitorados pelo postgres • podem usar memória compartilhada • podem executar transações • replicação lógica utiliza-os para • sincronismo inicial • aplicar mudanças provenientes da origem Timbira - A empresa brasileira de PostgreSQL 15 / 44
- 18. Resumo 1 Introdução 2 Arquitetura 3 Replicação Lógica 4 Configuração 5 Limitações 6 Conclusão Timbira - A empresa brasileira de PostgreSQL 16 / 44
- 19. Publicação • agrupar mudanças • cada publicação só existe em um banco de dados • tabela pode ser adicionada em múltiplas publicações • só contém tabelas • escolher mudanças (INSERT, UPDATE e/ou DELETE) • cada publicação pode ter múltiplas assinaturas • tabelas podem ser adicionadas, removidas ou substituídas a posteriori Timbira - A empresa brasileira de PostgreSQL 17 / 44
- 20. Publicação: Comandos CREATE PUBLICATION todas FOR ALL TABLES; CREATE PUBLICATION alteracoes FOR TABLE s1.usuarios, s2.processos, s2.movimentos WITH (publish = 'update, delete'); ALTER PUBLICATION pub1 ADD TABLE s3.anexos, s3.historico; ALTER PUBLICATION pub1 DROP TABLE s2.enderecos; ALTER PUBLICATION pub1 SET (publish = 'insert, delete'); DROP PUBLICATION pub2; Timbira - A empresa brasileira de PostgreSQL 18 / 44
- 21. Assinatura • define uma conexão para nó da publicação • define um conjunto de publicações das quais quer assinar • receberá mudanças via slot de replicação • nós assinantes podem criar publicações • múltiplas assinaturas de um mesmo nó de publicação (cuidado com sobreposição) • cada assinatura ativa recebe mudanças de um nó de publicação • slot de replicação criado automaticamente ao criar a assinatura • slot de replicação removido automaticamente ao remover a assinatura Timbira - A empresa brasileira de PostgreSQL 19 / 44
- 22. Assinatura • DDL não é replicado • replicação de tabelas com nomes diferentes ou esquemas distintos não é suportada • colunas da tabela devem ter o mesmo nome e tipo de dados • a ordem das colunas pode ser diferente • nó assinante pode ter colunas adicionais (preenchidos com valores padrão) • sincronização inicial é opcional • sincronização é perdida se assinatura for recriada Timbira - A empresa brasileira de PostgreSQL 20 / 44
- 23. Assinatura: Comandos CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.1.2.3 port=7654 user=foo dbname=bar' PUBLICATION pub1, alteracoes; CREATE SUBSCRIPTION sub2 CONNECTION 'host=172.16.5.8 user=joao dbname=loja' PUBLICATION todas, pub2 WITH (copy_data = false, enabled = false); ALTER SUBSCRIPTION sub0 CONNECTION 'host=10.1.1.7 user=foo dbname=bar'; ALTER SUBSCRIPTION sub2 ENABLE; ALTER SUBSCRIPTION todos REFRESH PUBLICATION; DROP SUBSCRIPTION sub5; Timbira - A empresa brasileira de PostgreSQL 21 / 44
- 24. Sincronização Inicial • processos logical replication sync • snapshot inicial (ponto de partida) • cópia em paralelo das diversas tabelas • slot temporário e cópia dos dados • modo de sincronização ao final da cópia • aplicar mudanças após snapshot Timbira - A empresa brasileira de PostgreSQL 22 / 44
- 25. Conflitos • operação DML vinda do nó de publicação viola restrições no nó assinante • replicação para • UPDATE e DELETE sem efeito não produz um conflito • detalhes do conflito no log do nó assinante • atraso na replicação Timbira - A empresa brasileira de PostgreSQL 23 / 44
- 26. Conflitos: Resolução • resolver conflito manualmente • alterar dados no nó assinante de modo que não conflitem com os dados vindos do nó de publicação • ignorar a transação que conflita com os dados atuais no nó assinante • pg_replication_origin_advance Timbira - A empresa brasileira de PostgreSQL 24 / 44
- 27. Resumo 1 Introdução 2 Arquitetura 3 Replicação Lógica 4 Configuração 5 Limitações 6 Conclusão Timbira - A empresa brasileira de PostgreSQL 25 / 44
- 28. Planejamento • versão 10 ou superior • qualquer sistema operacional / arquitetura • versões do PostgreSQL podem ser diferentes • mudanças no esquema do nó assinante • após todas as transações pendentes serem aplicadas • nomes de tabelas idênticos (incluindo mesmo esquema) • nomes de colunas e tipo de dados idênticos • podem haver colunas adicionais no nó assinante • tabelas sem chave primária • comandos UPDATE e DELETE • REPLICA IDENTITY • DEFAULT | USING INDEX fooi | FULL | NOTHING Timbira - A empresa brasileira de PostgreSQL 26 / 44
- 29. Planejamento • colocar na mesma publicação tabelas que participam de uma transação • evitar inconsistência de dados • gatilhos não disparam no nó assinante • registro provenientes do nó de publicação • parâmetro session_replication_role = replica • ALTER TABLE foo ENABLE REPLICA TRIGGER bar • ALTER TABLE foo ENABLE ALWAYS TRIGGER bar • cascateamento • não há configuração especial para habilitar a replicação em cascata • criar publicação no nó assinante • inscrever um nó ao nó assinante Timbira - A empresa brasileira de PostgreSQL 27 / 44
- 30. Funcionamento • role • regra pg_hba.conf • privilégio LOGIN • configuração • postgresql.conf • cópia do esquema das tabelas a serem replicadas para os nós assinantes • sincronismo inicial (opcional) • aplicação das mudanças nos nós assinantes • entrega • fluxo (stream) • walsender (nó de publicação) • logical replication worker (nó assinante) Timbira - A empresa brasileira de PostgreSQL 28 / 44
- 31. Configuração: Publisher postgresql.conf wal_level = logical Role de replicação CREATE ROLE joao LOGIN REPLICATION; pg_hba.conf host foo joao 10.1.1.2/32 md5 Timbira - A empresa brasileira de PostgreSQL 29 / 44
- 32. Configuração: Subscriber Restaurar esquema pg_dump -h 10.1.1.1 -s -U joao foo | psql -f - -U maria bar Timbira - A empresa brasileira de PostgreSQL 30 / 44
- 33. Configuração: Publisher Publicar tabelas foo=# create publication pub1 for table contas, historico, vendas; CREATE PUBLICATION Timbira - A empresa brasileira de PostgreSQL 31 / 44
- 34. Configuração: Subscriber Assinar tabelas bar=# create subscription sub1 connection ’host=10.1.1.1 user=joao dbname=foo’ publication pub1; CREATE SUBSCRIPTION Timbira - A empresa brasileira de PostgreSQL 32 / 44
- 35. Configuração: Parâmetros • publisher • wal_level: replica • max_replication_slots: 10 • max_wal_senders: 10 • subscriber • max_replication_slots: 10 • max_logical_replication_workers: 4 • max_worker_processes: 8 • max_sync_workers_per_subscription: 2 Timbira - A empresa brasileira de PostgreSQL 33 / 44
- 36. Monitoramento • visão pg_stat_replication (publisher) • visão pg_replication_slots (publisher) • visão pg_stat_subscription (subscriber) Timbira - A empresa brasileira de PostgreSQL 34 / 44
- 37. Monitoramento: Publisher foo=# select * from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 6590 usesysid | 10 usename | euler application_name | sub1 client_addr | client_hostname | client_port | -1 backend_start | 2017-07-11 12:12:59.940085-03 backend_xmin | state | streaming sent_lsn | 0/5DF4D00 write_lsn | 0/5DF4D00 flush_lsn | 0/5DF2A38 replay_lsn | 0/5DF4D00 write_lag | 00:00:00.000307 flush_lag | 00:00:00.000307 replay_lag | 00:00:00.000307 sync_priority | 0 sync_state | async Timbira - A empresa brasileira de PostgreSQL 35 / 44
- 38. Atraso da Replicação foo=# SELECT pg_size_pretty( pg_wal_lsn_diff(sent_lsn, replay_lsn)) as lag from pg_stat_replication; lag --------- 42 kB (1 registro) Versão 10 A função pg_xlog_location_diff foi renomeada para pg_wal_lsn_diff. Timbira - A empresa brasileira de PostgreSQL 36 / 44
- 39. Monitoramento: Publisher bench=# select * from pg_replication_slots; -[ RECORD 1 ]-------+---------- slot_name | sub1 plugin | pgoutput slot_type | logical datoid | 16436 database | bench temporary | f active | t active_pid | 6590 xmin | catalog_xmin | 9304 restart_lsn | 0/6D28B98 confirmed_flush_lsn | 0/6D28BD0 Timbira - A empresa brasileira de PostgreSQL 37 / 44
- 40. Monitoramento: Subscriber foo=# select * from pg_stat_subscription; -[ RECORD 1 ]---------+------------------------------ subid | 16445 subname | sub1 pid | 6589 relid | received_lsn | 0/6D28AF0 last_msg_send_time | 2017-07-11 17:07:10.402336-03 last_msg_receipt_time | 2017-07-11 17:07:10.402413-03 latest_end_lsn | 0/6D28AF0 latest_end_time | 2017-07-11 17:07:10.402336-03 -[ RECORD 2 ]---------+------------------------------ subid | 16466 subname | sub2 pid | 7094 relid | received_lsn | 0/6D28AF0 last_msg_send_time | 2017-07-11 17:07:10.419269-03 last_msg_receipt_time | 2017-07-11 17:07:10.419382-03 latest_end_lsn | 0/6D28AF0 latest_end_time | 2017-07-11 17:07:10.419269-03 Timbira - A empresa brasileira de PostgreSQL 38 / 44
- 41. Resumo 1 Introdução 2 Arquitetura 3 Replicação Lógica 4 Configuração 5 Limitações 6 Conclusão Timbira - A empresa brasileira de PostgreSQL 39 / 44
- 42. Limitações • replicação unidirecional: plugin encaminha tudo que chega a ele sem checar a origem • filtro por registro: filtragem por condições definidas pelo usuário (distribuição) • resolução de conflito: não é automática • prevalece registro da nó de publicação • prevalece registro do nó assinante • prevalece registro mais recente • prevalece registro mais antigo • tentar combinar registros • consistência de dados: não há tal comando/ferramenta Timbira - A empresa brasileira de PostgreSQL 40 / 44
- 43. Resumo 1 Introdução 2 Arquitetura 3 Replicação Lógica 4 Configuração 5 Limitações 6 Conclusão Timbira - A empresa brasileira de PostgreSQL 41 / 44
- 44. Questionamentos • A sua pergunta na lista pgbr-geral • A sua pergunta na lista pgsql-{general, hackers} • histórico das listas • blogs • http://planeta.postgresql.org.br • http://planet.postgresql.org • wiki • http://wiki.postgresql.org • IRC • irc.freenode.net • #postgresql • #postgresql-br Timbira - A empresa brasileira de PostgreSQL 42 / 44
- 45. Referências • PostgreSQL: https://www.postgresql.org/docs/10/ static/logical-replication.html • Slony-I: http://www.slony.info/ • Londiste: https://wiki.postgresql.org/wiki/SkyTools • Bucardo: http://www.bucardo.org/ • pgpool-II: http://www.pgpool.net/ • BDR: http://www.bdr-project.org/ • pglogical: https: //www.2ndquadrant.com/en/resources/pglogical/ Timbira - A empresa brasileira de PostgreSQL 43 / 44
- 46. Perguntas ? Euler Taveira de Oliveira euler@timbira.com.br http://www.timbira.com.br Timbira - A empresa brasileira de PostgreSQL 44 / 44