Usar pglogical para sincronizar dados entre instâncias

Todas as versões do Aurora PostgreSQL atualmente disponíveis são compatíveis com a extensão pglogical. A extensão pglogical é anterior ao recurso de replicação lógica funcionalmente similar que foi introduzido pelo PostgreSQL na versão 10. Para obter mais informações, consulte Usar a replicação lógica do PostgreSQL com o Aurora.

A extensão pglogical é compatível com a replicação lógica entre dois ou mais clusters de banco de dados Aurora PostgreSQL. Ela também é compatível com a replicação entre diferentes versões do PostgreSQL e entre bancos de dados executados em instâncias de banco de dados RDS para PostgreSQL e clusters de banco de dados Aurora PostgreSQL. A extensão pglogical usa um modelo de publicação e assinatura para replicar alterações em tabelas e outros objetos, como sequências, de um editor para um assinante. Ela depende de um slot de replicação para garantir que as alterações sejam sincronizadas de um nó do editor para um nó assinante, definido da seguinte forma.

Depois, você pode encontrar informações sobre a configuração da extensão pglogical.

Requisitos e limitações da extensão pglogical

Todas as versões atualmente disponíveis do Aurora PostgreSQL são compatíveis com a extensão pglogical.

Tanto o nó do editor quanto o do assinante devem estar configurados para replicação lógica.

As tabelas que você deseja replicar de assinante para editor devem ter os mesmos nomes e o mesmo esquema. Essas tabelas também devem conter as mesmas colunas, e as colunas devem usar os mesmos tipos de dados. As tabelas de editores e assinantes devem ter as mesmas chaves primárias. Recomendamos que você use somente a CHAVE PRIMÁRIA como restrição exclusiva.

As tabelas no nó do assinante podem ter mais restrições permissivas do que as do nó do editor para restrições CHECK e NOT NULL.

A extensão pglogical fornece recursos como replicação bidirecional que não são compatíveis com o recurso de replicação lógica incorporado ao PostgreSQL (versão 10 e superior). Para obter mais informações, consulte PostgreSQL bi-directional replication using pglogical (Replicação bidirecional do PostgreSQL usando pglogical).

Configurar a extensão pglogical

Para configurar a extensão pglogical em seu cluster de banco de dados Aurora PostgreSQL, adicione pglogical às bibliotecas compartilhadas no grupo de parâmetros de cluster de banco de dados personalizado para seu cluster de banco de dados Aurora PostgreSQL. Você também precisa definir o valor do parâmetro rds.logical_replication como 1, para ativar a decodificação lógica. Finalmente, você cria a extensão no banco de dados. Você pode usar o AWS Management Console ou a AWS CLI para essas tarefas.

Você deve ter permissões como a função rds_superuser para realizar essas tarefas.

As etapas a seguir pressupõem que seu cluster de banco de dados do Aurora PostgreSQL esteja associado a um grupo de parâmetros de cluster de banco de dados. Para obter informações sobre como criar um grupo de parâmetros de cluster de banco de dados, consulte Trabalhar com grupos de parâmetros.

Configurar a replicação lógica para o cluster de banco de dados Aurora PostgreSQL

O procedimento a seguir mostra como iniciar a replicação lógica entre dois clusters de banco de dados Aurora PostgreSQL. As etapas pressupõem que tanto a fonte (editor) quanto o destino (assinante) tenham a extensão pglogical configurada conforme detalhado em Configurar a extensão pglogical.

A configuração do nó do editor está concluída. Agora você pode configurar o nó de assinante para receber as atualizações do editor.

Desse ponto em diante, as alterações feitas na tabela do editor são replicadas na tabela do assinante.

Restabelecer a replicação lógica após uma atualização principal

Antes de realizar uma atualização de versão principal de um cluster de banco de dados do Aurora PostgreSQL que está sendo configurado como um nó de editor para replicação lógica, você deve eliminar todos os slots de replicação, mesmo aqueles que não estão ativos. Recomendamos que você desvie temporariamente as transações do banco de dados do nó do editor, elimine os slots de replicação, atualize o cluster de banco de dados do Aurora PostgreSQL, e, depois, restabeleça e reinicie a replicação.

Os slots de replicação são hospedados somente no nó do editor. O nó de assinante do Aurora PostgreSQL em um cenário de replicação lógica não tem slots a serem descartados. O processo de atualização da versão principal do Aurora PostgreSQL é compatível com a atualização do assinante para uma nova versão principal do PostgreSQL, independente do nó do editor. No entanto, o processo de atualização interrompe o processo de replicação e interfere na sincronização dos dados WAL entre o nó do editor e o nó do assinante. Você precisa restabelecer a replicação lógica entre o editor e o assinante depois de atualizar o editor, o assinante ou ambos. O procedimento a seguir mostra como determinar se a replicação foi interrompida e como resolver o problema.

Determinar se a replicação lógica foi interrompida

Você pode determinar se o processo de replicação foi interrompido consultando o nó do editor ou o nó do assinante da forma a seguir.

Se seu processo de replicação lógica tiver sido interrompido, você poderá restabelecer a replicação seguindo estas etapas.

Consulte o status do nó. Seu status deve ser replicating conforme mostrado neste exemplo.

SELECT subscription_name,status,slot_name
  FROM pglogical.show_subscription_status();
             subscription_name |   status    |              slot_name
-------------------------------+-------------+-------------------------------------
 docs_lab_subscription         | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)

Confira o status do slot de replicação do assinante no nó do editor. A coluna active do slot deve retornar t (true), indicando que a replicação foi restabelecida.

SELECT slot_name,plugin,slot_type,active
  FROM pg_replication_slots;
                    slot_name              |      plugin      | slot_type | active
-------------------------------------------+------------------+-----------+--------
 pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical   | t
(1 row)

Gerenciar slots de replicação lógica para Aurora PostgreSQL

Antes de realizar uma atualização de versão principal de uma instância de gravador do cluster de banco de dados do Aurora PostgreSQL que está atuando como um nó de editor em um cenário de replicação lógica, você deve eliminar os slots de replicação na instância. O processo de pré-conferência da atualização da versão principal notifica você de que a atualização não pode continuar até que os slots sejam eliminados.

Para identificar os slots de replicação que foram criados usando a extensão pglogical, faça login em cada banco de dados e obtenha o nome dos nós. Ao consultar o nó do assinante, você obtém os nós do editor e do assinante na saída, conforme mostrado neste exemplo.

SELECT * FROM pglogical.node;
node_id   |     node_name
------------+-------------------
 2182738256 | docs_lab_target
 3410995529 | docs_lab_provider
(2 rows)

Você pode obter os detalhes sobre a assinatura com a consulta a seguir.

SELECT sub_name,sub_slot_name,sub_target
  FROM pglogical.subscription;
 sub_name |         sub_slot_name          | sub_target
----------+--------------------------------+------------
  docs_lab_subscription     | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)

Agora você pode cancelar a assinatura da forma a seguir.

SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
 drop_subscription
-------------------
                 1
(1 row)

Depois de cancelar a assinatura, você pode excluir o nó.

SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
 drop_node
-----------
 t
(1 row)

Você pode verificar se o nó não existe mais da forma a seguir.

SELECT * FROM pglogical.node;
 node_id | node_name
---------+-----------
(0 rows)

Referência de parâmetros da extensão pglogical

Na tabela, você pode encontrar parâmetros associados à extensão pglogical. Parâmetros como pglogical.conflict_log_level e pglogical.conflict_resolution são usados para lidar com conflitos de atualização. Podem surgir conflitos quando alterações são feitas localmente nas mesmas tabelas que estão inscritas para receber alterações do editor. Os conflitos também podem ocorrer durante vários cenários, como replicação bidirecional ou quando vários assinantes estão se replicando do mesmo editor. Para obter mais informações, consulte PostgreSQL bi-directional replication using pglogical (Replicação bidirecional do PostgreSQL usando pglogical).