Particionamento de replicação lógica com PostgreSQL 13

Cada versão do PostgreSQL vem com alguns aprimoramentos importantes de recursos, mas o que é igualmente interessante é que cada versão também aprimora seus recursos anteriores.

Como o PostgreSQL 13 está programado para ser lançado em breve, é hora de verificar quais recursos e melhorias a comunidade está nos trazendo. Uma dessas melhorias sem ruído é a “Melhoria de replicação lógica para particionamento”.

Vamos entender essa melhoria de recurso com um exemplo em execução.

Terminologia

Dois termos importantes para entender esse recurso são:

• Tabelas de partição
• Replicação lógica

Tabelas de partição

Uma maneira de dividir uma mesa grande em várias partes físicas para obter benefícios como:

• Melhor desempenho de consulta
• Atualizações mais rápidas
• Carregamentos e exclusões em massa mais rápidos
• Organização de dados raramente usados ​​em unidades de disco lentas

Algumas dessas vantagens são alcançadas por meio de remoção de partição (ou seja, planejador de consulta usando definição de partição para decidir se a varredura de uma partição ou não) e o fato de que uma partição é mais fácil de caber em memória finita em comparação com uma mesa enorme.

Uma tabela é particionada com base em:

• Lista
• Hash
• Intervalo

Replicação lógica 

Como o nome indica, este é um método de replicação no qual os dados são replicados de forma incremental com base em sua identidade (por exemplo, chave). Não é semelhante ao WAL ou métodos de replicação física em que os dados são enviados byte a byte.

Com base em um padrão Publicador-Assinante, a origem dos dados precisa definir um publicador enquanto o destino precisa ser registrado como assinante. Os casos de uso interessantes para isso são:

• Replicação seletiva (apenas parte do banco de dados)
• Gravações simultâneas em duas instâncias do banco de dados em que os dados estão sendo replicados
• Replicação entre diferentes sistemas operacionais (por exemplo, Linux e Windows)
• Segurança refinada na replicação de dados 
• Aciona a execução à medida que os dados chegam no lado do receptor 

Replicação lógica para partições

Com os benefícios da replicação lógica e do particionamento, é um caso de uso prático ter um cenário em que uma tabela particionada precisa ser replicada em duas instâncias do PostgreSQL.

A seguir estão os passos para estabelecer e destacar a melhoria que está sendo feita no PostgreSQL 13 neste contexto.

Configuração

Considere uma configuração de dois nós para executar duas instâncias diferentes contendo tabela particionada:

As etapas na Instância_1 são como abaixo após o login em 192.168.56.101 como usuário postgres :

$ initdb -D ${HOME}/pgdata-1

$ echo "listen_addresses = '192.168.56.101'"  >> ${HOME}/pgdata-1/postgresql.conf

$ echo "wal_level = logical"                  >> ${HOME}/pgdata-1/postgresql.conf

$ echo "host postgres all 192.168.56.102/32 md5" >> ${HOME}/pgdata-1/pg_hba.conf

$ pg_ctl -D ${HOME}/pgdata-1 -l logfile start

A configuração 'wal_level' é definida especificamente como 'logical' para indicar que a replicação lógica será usada para replicar dados desta instância. O arquivo de configuração ‘pg_hba.conf’ também foi modificado para permitir conexões de 192.168.56.102.

# CREATE TABLE stock_sales

( sale_date date not null, unit_sold  int, unit_price int )

  PARTITION BY RANGE ( sale_date );

# CREATE TABLE stock_sales_y2017 PARTITION OF stock_sales

  FOR VALUES FROM ('2017-01-01') TO ('2018-01-01'); 

# CREATE TABLE stock_sales_y2018 PARTITION OF stock_sales

  FOR VALUES FROM ('2018-01-01') TO ('2019-01-01');

# CREATE TABLE stock_sales_default

  PARTITION OF stock_sales DEFAULT;

Embora a função postgres seja criada por padrão no banco de dados Instance_1, um usuário separado também deve ser criado com acesso limitado – o que restringe o escopo apenas para uma determinada tabela.

# CREATE ROLE rep_usr WITH REPLICATION LOGIN PASSWORD 'rep_pwd';

# GRANT CONNECT ON DATABASE postgres TO rep_usr;

# GRANT USAGE ON SCHEMA public TO rep_usr;

# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep_usr;

Uma configuração quase semelhante é necessária em Instance_2

$ initdb -D ${HOME}/pgdata-2

$ echo "listen_addresses = '192.168.56.102'"  >> ${HOME}/pgdata-2/postgresql.conf

$ pg_ctl -D ${HOME}/pgdata-2 -l logfile start

Deve-se notar que, como Instance_2 não será uma fonte de dados para nenhum outro nó, as configurações wal_level, bem como o arquivo pg_hba.conf, não precisam de configurações extras. Desnecessário dizer que o pg_hba.conf pode precisar de atualização conforme as necessidades de produção.

Replicação lógica não suporta DDL, precisamos criar uma estrutura de tabela em Instance_2 também. Crie uma tabela particionada usando a criação de partição acima para criar a mesma estrutura de tabela em Instance_2 também.

Configuração de replicação lógica

A configuração da replicação lógica fica muito mais fácil com o PostgreSQL 13. Até o PostgreSQL 12 a estrutura era como abaixo:

Com o PostgreSQL 13, a publicação de partições fica muito mais fácil. Consulte o diagrama abaixo e compare com o diagrama anterior:

Com configurações com centenas e milhares de tabelas particionadas – essa pequena mudança simplifica coisas em grande medida.

No PostgreSQL 13, as instruções para criar tal publicação serão:

CREATE PUBLICATION rep_part_pub FOR TABLE stock_sales 

WITH (publish_via_partition_root);

O parâmetro de configuração publish_via_partition_root é novo no PostgreSQL 13, que permite que o nó destinatário tenha uma hierarquia folha ligeiramente diferente. A mera criação de publicações em tabelas particionadas no PostgreSQL 12 retornará instruções de erro como abaixo:

ERROR:  "stock_sales" is a partitioned table

DETAIL:  Adding partitioned tables to publications is not supported.

HINT:  You can add the table partitions individually.

Ignorando as limitações do PostgreSQL 12, e continuando com este recurso no PostgreSQL 13, temos que estabelecer o subscriber no Instance_2 com as seguintes instruções:

CREATE SUBSCRIPTION rep_part_sub CONNECTION 'host=192.168.56.101 port=5432 user=rep_usr password=rep_pwd dbname=postgres' PUBLICATION rep_part_pub;

Verificando se realmente funciona

Já terminamos toda a configuração, mas vamos fazer alguns testes para ver se as coisas estão funcionando.

Na Instance_1, insira várias linhas garantindo que elas sejam geradas em várias partições:

# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2017-09-20', 12, 151);# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2018-07-01', 22, 176);

# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2016-02-02', 10, 1721);

Verifique os dados em Instance_2:

# SELECT * from stock_sales; 

sale_date  | unit_sold | unit_price

------------+-----------+------------

 2017-09-20 |    12 |    151

 2018-07-01 |    22 |    176

 2016-02-02 |    10 |   1721

Agora vamos verificar se a replicação lógica funciona mesmo que os nós folha não sejam os mesmos no lado do destinatário.

Adicione outra partição em Instance_1 e insira o registro:

# CREATE TABLE stock_sales_y2019

      PARTITION OF stock_sales 

     FOR VALUES FROM ('2019-01-01') to ('2020-01-01');

# INSERT INTO stock_sales VALUES(‘2019-06-01’, 73, 174 );

Verifique os dados em Instance_2:

# SELECT * from stock_sales;

 sale_date  | unit_sold | unit_price

------------+-----------+------------

 2017-09-20 |    12 |    151

 2018-07-01 |    22 |    176

 2016-02-02 |    10 |   1721

 2019-06-01 |    73 |   174

Outros recursos de particionamento no PostgreSQL 13

Há também outras melhorias no PostgreSQL 13 relacionadas ao particionamento, a saber:

1. Melhorias na junção entre tabelas particionadas
2. Tabelas particionadas agora são compatíveis com gatilhos de nível de linha ANTES

Conclusão