ApsaraDB RDS:Usar um replication slot para CDC

Pré-requisitos

• Você possui uma instância ApsaraDB RDS for PostgreSQL. Para mais informações, consulte Crie uma instância ApsaraDB RDS for PostgreSQL.

• Configure uma lista de permissões para permitir o acesso do cliente à instância ApsaraDB RDS for PostgreSQL. Para mais informações, consulte Configurar uma lista de permissões de endereços IP.

• Instale o cliente de linha de comando do PostgreSQL. Para mais detalhes, acesse a documentação oficial do PostgreSQL.

Observações de uso

• A ativação do CDC e o consumo de alterações de dados são suportados apenas na instância primária. Instâncias somente leitura não oferecem esse recurso.

• O ApsaraDB RDS for PostgreSQL suporta Logical Replication Slot Failover. Uma alternância entre primário e secundário não afeta o CDC. Para mais informações, consulte Logical Replication Slot Failover.

• Antes de ativar o CDC, modifique um parâmetro da sua instância ApsaraDB RDS for PostgreSQL. Essa ação reinicia a instância. Para evitar interrupções no serviço, execute essa operação fora dos horários de pico.

• Ao utilizar o CDC em uma instância ApsaraDB RDS for PostgreSQL, observe os seguintes pontos:

  • O CDC exige mais espaço de armazenamento para logs WAL. Caso o consumo de dados apresente anomalias ou seja interrompido, a instância não limpa os logs WAL automaticamente. Isso pode causar acúmulo de logs até ocupar todo o espaço em disco disponível, bloqueando potencialmente a instância. Uma instância bloqueada torna-se somente leitura e rejeita operações de escrita.

  • Manter linhas de dados antigas por um longo período pode levar a um problema de wraparound de ID de transação, que bloqueia todas as operações de escrita na instância. O log de erros pode conter as seguintes mensagens:

    “HINT: Close open transactions soon to avoid wraparound problems. You might also need to commit or roll back old prepared transactions, or drop stale replication slots.”
    “WARNING: oldest xmin is far in the past.”

  Exclua manualmente o replication slot para permitir que o kernel do PostgreSQL limpe automaticamente logs WAL antigos e linhas de dados. Para mais informações, consulte Desativar o CDC.

  Nota

  Monitore regularmente o tamanho dos logs WAL e o uso de espaço em disco da sua instância, além de configurar alertas relevantes. Para mais informações, consulte Visualize dados do Enhanced Monitoring e Gerencie regras de alerta.

Ative o CDC

Etapa 1: Crie um banco de dados de teste

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em no ID da instância.

2. No painel de navegação à esquerda, escolha Databases.

3. Clique em Create Database. Após a criação do banco de dados testdb, seu status muda para Running e seu conjunto de caracteres é definido como UTF8.

   Nota

   Neste exemplo, cria-se um banco de dados chamado testdb. Para instruções detalhadas, consulte Crie um banco de dados.

Etapa 2: Crie contas de teste e configure permissões

1. No painel de navegação à esquerda, escolha Accounts.

2. Clique em Create Account para criar uma conta privilegiada (db_admin) e uma conta padrão para CDC (cdc_user).

   Nota

   Os nomes de conta utilizados neste tópico servem apenas para fins de demonstração. Defina nomes personalizados conforme necessário. Para mais informações sobre como criar uma conta, consulte Crie uma conta.

3. Utilize a conta db_admin para conectar-se à instância ApsaraDB RDS for PostgreSQL.

   psql -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -p 5432 -U db_admin -d testdb

   Nota

   Para mais informações sobre como obter o endpoint de uma instância, consulte Visualize ou altere o endpoint e o número da porta.

4. Execute o seguinte comando para adicionar a conta cdc_user à função de replicação:

   ALTER USER cdc_user WITH REPLICATION;

   Verifique o resultado executando o comando abaixo:

   SELECT rolreplication FROM  pg_roles WHERE rolname='cdc_user';

   Saída de exemplo:

    rolreplication
   ----------------
    t
   (1 row)

5. Conceda permissões à conta cdc_user com o seguinte comando:

   GRANT SELECT ON ALL TABLES IN SCHEMA PUBLIC to cdc_user;

Etapa 3: Modifique parâmetros da instância

1. Consulte as configurações atuais dos parâmetros executando este comando:

   SELECT name,
          setting,
          short_desc,
          source
   FROM pg_settings
   WHERE name ='wal_level';

   Saída de exemplo:

            name          | setting |                               short_desc                                |       source
   -----------------------+---------+-------------------------------------------------------------------------+--------------------
    wal_level             | replica | Sets the level of information written to the WAL.                       | configuration file
   (1 rows)

   O parâmetro wal_level controla a quantidade de informações que o PostgreSQL grava no log WAL. O valor padrão é replica. Esse parâmetro só pode ser definido na inicialização do servidor. Valores válidos:

   • minimal: Grava apenas as informações necessárias para recuperação após falha ou desligamento imediato. Nesse nível, não é possível restaurar um banco de dados a partir de um backup base e logs WAL.

   • replica: Registra informações suficientes para suportar arquivamento e replicação de WAL, incluindo a execução de consultas somente leitura em um servidor standby.

   • logical: Adiciona as informações necessárias para decodificação lógica.

2. Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em no ID da instância.

3. No painel de navegação à esquerda, escolha Parameters.

4. Defina o parâmetro wal_level como logical.

   Nota

   • Para mais informações sobre como modificar parâmetros da instância, consulte Modifique os parâmetros de uma instância ApsaraDB RDS for PostgreSQL.

   • Após enviar a alteração do parâmetro, sua instância ApsaraDB RDS for PostgreSQL será reiniciada. Para evitar interrupções no serviço, execute essa operação fora dos horários de pico.

Etapa 4: Crie um replication slot lógico

1. Conecte-se à instância ApsaraDB RDS for PostgreSQL usando a conta db_admin.

   psql -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -p 5432 -U db_admin -d testdb

2. Crie um replication slot chamado cdc_replication_slot utilizando o plugin de saída test_decoding com o comando a seguir:

   SELECT pg_create_logical_replication_slot('cdc_replication_slot', 'test_decoding');

   Nota

   • O nome do slot cdc_replication_slot é usado apenas para demonstração. Especifique um nome personalizado conforme necessário.

   • O PostgreSQL fornece nativamente o plugin de saída test_decoding, portanto, nenhuma alteração é necessária.

   Saída de exemplo:

    pg_create_logical_replication_slot
   ------------------------------------
    (cdc_replication_slot,1/14003428)
   (1 row)

   Verifique se o slot foi criado executando o seguinte comando:

   SELECT * FROM pg_replication_slots;

   Saída de exemplo:

         slot_name       |    plugin     | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size  | two_phase
   ----------------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+----------------+-----------
    cdc_replication_slot | test_decoding | logical   |  18822 | testdb   | f         | f      |            |      |        22356 | 1/140033F0  | 1/14003428          | reserved   |                | f
   (1 row)

Etapa 5: Crie dados de teste

CREATE TABLE public.tb_test(
    id int NOT NULL PRIMARY KEY
);
ALTER TABLE public.tb_test ADD name varchar(1) NULL;
INSERT INTO public.tb_test SELECT 1, 'A';

Etapa 6: Ler dados do slot

1. Utilize a conta cdc_user para conectar-se à instância ApsaraDB RDS for PostgreSQL.

   psql -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -p 5432 -U cdc_user -d testdb

2. Leia as alterações do replication slot com o seguinte comando:

   SELECT * FROM pg_logical_slot_peek_changes('cdc_replication_slot', null, null);

   Saída de exemplo:

       lsn     |  xid  |                                  data
   ------------+-------+-------------------------------------------------------------------------
    1/14003D90 | 22376 | BEGIN 22376
    1/1401DDE8 | 22376 | COMMIT 22376
    1/1401DDE8 | 22377 | BEGIN 22377
    1/1401E100 | 22377 | COMMIT 22377
    1/1401E2A8 | 22382 | BEGIN 22382
    1/1401E2A8 | 22382 | table public.tb_test: INSERT: id[integer]:1 name[character varying]:'A'
    1/1401E3C0 | 22382 | COMMIT 22382
   (7 rows)

Etapa 7: Consumir alterações de dados

1. Encerre a conexão com o banco de dados usando o comando \q.

2. Consuma as alterações de dados executando o comando a seguir:

   Nota

   Execute o comando pg_recvlogical como usuário postgres. Alterne de usuário executando o comando su - postgres. Se encontrar o erro -bash: pg_recvlogical: command not found, consulte a seção Perguntas frequentes para obter uma solução.

   pg_recvlogical -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -U <privileged account> -d <test database> --create-slot --if-not-exists --slot=cdc_replication_slot --plugin=test_decoding --start -f -

   Exemplo de comando:

   pg_recvlogical -h pgm-*****.pgsql.singapore.rds.aliyuncs.com -U db_admin -d testdb --create-slot --if-not-exists --slot=cdc_replication_slot --plugin=test_decoding --start -f -

   Saída de exemplo:

   BEGIN 22376
   COMMIT 22376
   BEGIN 22377
   COMMIT 22377
   BEGIN 22382
   table public.tb_test: INSERT: id[integer]:1 name[character varying]:'A'
   COMMIT 22382

Desativar o CDC

Se o consumo de dados apresentar anomalias ou parar, os logs WAL podem se acumular e ocupar todo o espaço em disco disponível, acabando por bloquear a instância. Para resolver isso, exclua manualmente os replication slots inativos, permitindo que o kernel do PostgreSQL limpe os logs WAL antigos.

Perguntas frequentes

• P: O que fazer ao receber o erro -bash: pg_recvlogical: command not found durante o consumo de dados?

  R: O pg_recvlogical é uma ferramenta nativa de decodificação lógica do PostgreSQL que utiliza o plugin de saída padrão test_decoding. Esse plugin encontra-se no diretório contrib/test_decoding do pacote de código-fonte do PostgreSQL. Compile e instale o PostgreSQL a partir do código-fonte. Após a instalação, a ferramenta pg_recvlogical estará disponível no diretório /bin do caminho de instalação do cliente. Para mais informações sobre como instalar o PostgreSQL a partir do código-fonte, consulte Installation from Source Code.

• P: Excluí manualmente um replication slot, mas o sistema não limpou automaticamente os logs WAL e eles continuam ocupando espaço em disco. Como proceder?

  R: Altere o parâmetro wal_keep_segments para seu valor padrão de 128 a fim de reduzir a quantidade de arquivos de log retidos. Para mais detalhes sobre como modificar parâmetros da instância, consulte Modifique os parâmetros de uma instância ApsaraDB RDS for PostgreSQL.