Usar replicação lógica para realizar uma atualização de versão principal do Aurora PostgreSQL

PDFRSS

Ao usar a replicação lógica e a clonagem rápida do Aurora, você pode realizar um upgrade de versão principal que usa a versão atual do banco de dados Aurora PostgreSQL enquanto migra gradualmente os dados alterados para o novo banco de dados da versão principal. Esse processo de upgrade com baixo tempo de inatividade é chamado de upgrade azul/verde. A versão atual do banco de dados é chamada de ambiente “azul” e a nova versão do banco de dados é chamada de ambiente “verde”.

A clonagem rápida do Aurora carrega totalmente os dados existentes ao tirar um snapshot do banco de dados de origem. A clonagem rápida usa um protocolo de cópia em gravação construído sobre a camada de armazenamento do Aurora, que permite criar um clone do banco de dados em pouco tempo. Esse método é muito eficaz ao realizar a atualização para um banco de dados grande.

A replicação lógica no PostgreSQL rastreia e transfere suas alterações de dados da instância inicial para uma nova instância executada em paralelo até que você mude para a versão mais recente do PostgreSQL. A replicação lógica usa um modelo de publicação e de assinatura. Para obter mais informações sobre a replicação lógica do Aurora PostgreSQL, consulte Replicação com Amazon Aurora PostgreSQL.

dica

É possível minimizar o tempo de inatividade necessário para a atualização da versão principal utilizando o recurso de implantação azul/verde gerenciado do Amazon RDS. Para ter mais informações, consulte Usar implantações azul/verde do Amazon Aurora para atualizações de banco de dados.

Requisitos

Você deve cumprir os seguintes requisitos para realizar esse processo de upgrade com baixo tempo de inatividade:

• Você deve ter permissões rds_superuser.

• O cluster de banco de dados do Aurora PostgreSQL que você pretende fazer upgrade deve estar executando uma versão compatível que possa realizar upgrades de versão principal usando replicação lógica. Aplique patches e atualizações da versão secundária ao cluster de banco de dados. A função aurora_volume_logical_start_lsn usada nessa técnica é compatível com as seguintes versões do Aurora PostgreSQL:

  • Versão 15.2 e versões 15 posteriores

  • Versão 14.3 e versões 14 posteriores

  • Versão 13.6 e versões 13 posteriores

  • Versão 12.10 e versões 12 posteriores

  • Versão 11.15 e versões 11 posteriores

  • Versão 10.20 e versões 10 posteriores

  Para obter mais informações sobre a função aurora_volume_logical_start_lsn, consulte aurora_volume_logical_start_lsn.

• Todas as suas tabelas devem ter uma chave primária ou incluir uma coluna de identidade do PostgreSQL.

• Configure o grupo de segurança para sua VPC para permitir acesso de entrada e saída entre os dois clusters de banco de dados do Aurora PostgreSQL, antigo e novo. Você pode conceder acesso a um intervalo Encaminhamento Entre Domínios Sem Classificação (CIDR) específico ou a outro grupo de segurança em sua VPC ou em uma VPC par. (A VPC de par requer uma conexão de emparelhamento da VPC.)

nota

Para obter informações detalhadas sobre as permissões necessárias para configurar e gerenciar um cenário de replicação lógica em execução, consulte a documentação principal do PostgreSQL.

Limitações

Ao realizar um upgrade com baixo tempo de inatividade em seu cluster de banco de dados do Aurora PostgreSQL para uma nova versão principal, você usa o atributo nativo de replicação lógica do PostgreSQL. Ele tem os mesmos recursos e limitações da replicação lógica do PostgreSQL. Para obter mais informações, consulte Replicação lógica do PostgreSQL.

• Comandos DDL (Data Definition Language) não são replicados.

• A replicação não é compatível com alterações de esquema em um banco de dados ativo. O esquema é recriado em sua forma original durante o processo de clonagem. Se você alterar o esquema após a clonagem, mas antes de concluir a atualização, isso não será refletido na instância atualizada.

• Objetos grandes não são replicados, mas você pode armazenar dados em tabelas normais.

• A replicação só é compatível com tabelas, por exemplo, tabelas particionadas. A replicação para outros tipos de relações, como visualizações, visões materializadas ou tabelas externas, não é compatível.

• Os dados da sequência não são replicados e exigem uma atualização manual após o failover.

nota

Essa atualização não é compatível com a criação de scripts automáticos. Você deve executar todas as etapas manualmente.

Definir e conferir valores de parâmetros

Antes de atualizar, configure a instância do gravador de seu cluster de banco de dados do Aurora PostgreSQL para atuar como um servidor de publicação. A instância deve usar um grupo de parâmetros do cluster de banco de dados personalizado com as seguintes configurações:

• rds.logical_replication: defina este parâmetro como 1. O parâmetro rds.logical_replication tem a mesma finalidade do parâmetro wal_level de um servidor PostgreSQL independente e de outros parâmetros que controlam o gerenciamento de arquivos de log de gravação antecipada.

• max_replication_slots: defina esse parâmetro como o número total de assinaturas que você pretende criar. Se você estiver usando o AWS DMS, defina esse parâmetro como o número de tarefas AWS DMS que você planeja usar para a captura de dados de alteração desse cluster de banco de dados.

• max_wal_senders: defina o número de conexões simultâneas, além de algumas extras, para disponibilizar para tarefas de gerenciamento e novas sessões. Se você estiver usando AWS DMS, o número de max_wal_senders deve ser igual ao número de sessões simultâneas mais o número de AWS DMS tarefas que podem estar funcionando a qualquer momento.

• max_logical_replication_workers: defina como o número de operadores de replicação lógica e operadores de sincronização de tabelas que você espera. Geralmente, é seguro definir o número de operadores de replicação como o mesmo valor usado para max_wal_senders. Os operadores são retirados do grupo de processos em segundo plano (max_worker_processes) alocados para o servidor.

• max_worker_processes: defina o número de processos em segundo plano para o servidor. Esse número deve ser grande o suficiente para alocar operadores para replicação, processos de autovacuum e outros processos de manutenção que possam ocorrer simultaneamente.

Ao atualizar para uma versão mais recente do Aurora PostgreSQL, você precisa duplicar todos os parâmetros que você modificou na versão anterior do grupo de parâmetros. Esses parâmetros são aplicados à versão atualizada. Você pode consultar a tabela pg_settings para obter uma lista de configurações de parâmetros para poder recriá-las em seu novo cluster de banco de dados do Aurora PostgreSQL.

Por exemplo, para obter as configurações dos parâmetros de replicação, execute a seguinte consulta:

SELECT name, setting FROM pg_settings WHERE name in 
('rds.logical_replication', 'max_replication_slots', 
'max_wal_senders', 'max_logical_replication_workers', 
'max_worker_processes');

Atualizar o Aurora PostgreSQL para uma nova versão principal

Como preparar o editor (azul)

1. No exemplo a seguir, a instância do gravador de código-fonte (azul) é um cluster de banco de dados do Aurora PostgreSQL executando o PostgreSQL versão 11.15. Esse é o nó de publicação em nosso cenário de replicação. Para essa demonstração, nossa instância de gravador de origem hospeda uma tabela de amostra que contém uma série de valores:

   CREATE TABLE my_table (a int PRIMARY KEY);
   INSERT INTO my_table VALUES (generate_series(1,100));

2. Para criar uma publicação na instância de origem, conecte-se ao nó de gravação da instância com psql (a CLI do PostgreSQL) ou com o cliente de sua escolha). Insira o seguinte comando em cada banco de dados:

   CREATE PUBLICATION publication_name FOR ALL TABLES;

   O publication_name especifica o nome da publicação.

3. Também é necessário criar um slot de replicação na instância. O comando a seguir cria um slot de replicação e carrega o plug-in de decodificação lógica pgoutput. O plug-in altera o conteúdo lido do registro em log de gravação antecipada (WAL) para o protocolo de replicação lógica e filtra os dados de acordo com a especificação da publicação.

   SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');

Como clonar o editor

1. Use o console do Amazon RDS para criar um clone da instância de origem. Destaque o nome da instância no console do Amazon RDS e selecione Create clone (Criar clone) no menu Actions (Ações).

   

2. Forneça um nome único para a instância. A maioria das configurações é padrões da instância de origem. Quando você tiver feito as alterações necessárias para a nova instância, selecione Create clone (Criar clone).

   

3. Enquanto a instância de destino está sendo iniciada, a coluna Status do nó do gravador exibe Creating (Criando) na coluna Status. Quando a instância estiver pronta, seu status mudará para Available (Disponível).

Como preparar o clone para uma atualização

1. O clone é a instância “verde” no modelo de implantação. É o host do nó de assinatura de replicação. Quando o nó estiver disponível, conecte-se ao psql e consulte o novo nó do gravador para obter o número de sequência de log (LSN). O LSN identifica o início de um registro no fluxo WAL.

   SELECT aurora_volume_logical_start_lsn();

2. Na resposta da consulta, você encontra o número LSN. Você precisará desse número posteriormente no processo, então anote-o.

   postgres=> SELECT aurora_volume_logical_start_lsn();
   aurora_volume_logical_start_lsn 
   ---------------
   0/402E2F0
   (1 row)
   

3. Antes de atualizar o clone, descarte o slot de replicação do clone.

   SELECT pg_drop_replication_slot('replication_slot_name');

Como atualizar um cluster para uma nova versão principal

• Depois de clonar o nó do provedor, use o console do Amazon RDS para iniciar uma atualização de versão principal no nó de assinatura. Destaque o nome da instância no console do RDS e selecione o botão Modify (Modificar). Selecione a versão atualizada e seus grupos de parâmetros atualizados e aplique as configurações imediatamente para atualizar a instância de destino.

  

• Você também pode usar a CLI para realizar uma atualização:

  aws rds modify-db-cluster —db-cluster-identifier $TARGET_Aurora_ID —engine-version 13.6 —allow-major-version-upgrade —apply-immediately

Como preparar o assinante (verde)

1. Quando o clone ficar disponível depois do upgrade, conecte-se com o psql e defina a assinatura. Para fazer isso, é necessário especificar as seguintes opções no comando CREATE SUBSCRIPTION:

   • subscription_name: o nome da inscrição.

   • admin_user_name: o nome de um usuário administrativo com permissões rds_superuser.

   • admin_user_password: a senha associada ao usuário administrativo.

   • source_instance_URL: o URL da instância do servidor de publicação.

   • database: o banco de dados ao qual o servidor de assinatura se conectará.

   • publication_name: o nome do servidor de publicação.

   • replication_slot_name: o nome do slot de replicação.

   CREATE SUBSCRIPTION subscription_name 
   CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name 
   WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');

2. Depois de criar a assinatura, consulte a visualização pg_replication_origin para recuperar o valor do roname, que é o identificador da origem da replicação. Cada instância tem um roname:

   SELECT * FROM pg_replication_origin;

   Por exemplo:

   postgres=> 
   SELECT * FROM pg_replication_origin;
    
   roident | roname 
   ---------+----------
   1 | pg_24586
   

3. Forneça a LSN que você salvou da consulta anterior do nó de publicação e o roname retornado do nó de assinatura [INSTANCE] no comando. Esse comando usa a função pg_replication_origin_advance para especificar o ponto de partida na sequência de log para replicação.

   SELECT pg_replication_origin_advance('roname', 'log_sequence_number');

   roname é o identificador retornado pela visualização pg_replication_origin.

   log_sequence_number é o valor retornado pela consulta anterior da função aurora_volume_logical_start_lsn.

4. Depois, use a cláusula ALTER SUBSCRIPTION... ENABLE para ativar a replicação lógica.

   ALTER SUBSCRIPTION subscription_name ENABLE;

5. Nesse momento, você pode confirmar que a replicação está funcionando. Adicione um valor à instância de publicação e, depois, confirme se o valor foi replicado no nó de assinatura.

   Depois, use o seguinte comando para monitorar o atraso de replicação no nó de publicação:

   SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
   confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(),
   confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';

   Por exemplo:

   postgres=> SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 
   confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
    
   current_time                   | slot_name             | active | active_pid | diff_size | diff_bytes 
   -------------------------------+-----------------------+--------+------------+-----------+------------
   2022-04-13 15:11:00.243401+00  | replication_slot_name | t      | 21854      | 136 bytes | 136
   (1 row)
   

   Você pode monitorar o atraso na replicação usando os valores diff_size e diff_bytes. Quando esses valores atingem 0, isso mostra que a réplica alcançou a instância do banco de dados de origem.

Executar tarefas de pós-atualização

Quando a atualização for concluída, o status da instância será exibido como Available (Disponível) na coluna Status do painel do console. Na nova instância, recomendamos fazer o seguinte:

• Redirecione suas aplicações para apontar para o nó do gravador.

• Adicione nós de leitura para gerenciar o número de casos e fornecer alta disponibilidade no caso de um problema com o nó do gravador.

• Os clusters de banco de dados do Aurora PostgreSQL ocasionalmente exigem atualizações do sistema operacional. Essas atualizações às vezes incluem uma versão mais recente da biblioteca glibc. Durante essas atualizações, recomendamos que você siga as diretrizes descritas em Agrupamentos compatíveis com Aurora PostgreSQL.

• Atualize as permissões do usuário na nova instância para garantir o acesso.

Depois de testar sua aplicação e seus dados na nova instância, recomendamos que você faça um backup final da instância inicial antes de removê-la. Para ter mais informações sobre o uso de replicação lógica em um host do Aurora, consulte Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL.