Todos os produtos
Search
Central de documentação

ApsaraDB RDS:Online partitioning feature (rds_online_migrate)

Última atualização: Oct 13, 2026

A extensão rds_online_migrate para ApsaraDB RDS for PostgreSQL oferece um recurso de particionamento online. Esse recurso permite converter uma tabela padrão em uma tabela particionada.

Contexto

Conforme os negócios crescem, o volume de dados aumenta. Em certos cenários, talvez seja necessário converter uma tabela padrão em uma tabela particionada. No entanto, o PostgreSQL nativo não oferece conversão online. Para simplificar as operações e manutenção (O&M) e reduzir o impacto do particionamento nos negócios, o ApsaraDB RDS for PostgreSQL disponibiliza esse recurso de particionamento online.

Aplicabilidade

Sua instância do ApsaraDB RDS for PostgreSQL deve atender aos seguintes requisitos:

  • Versão principal: 13 ou superior.

  • Versão secundária do mecanismo: 20251130 ou superior.

Precauções

Antes de executar o particionamento online, revise as informações abaixo para garantir a segurança dos dados e o sucesso da operação.

  • Preparativos

    • Backup e testes: Antes de qualquer operação, confirme que você possui um backup completo válido. Recomendamos também testar e verificar rigorosamente em ambiente de não produção.

    • Planejamento de espaço de armazenamento: Durante o particionamento online, o sistema cria uma nova tabela para migração de dados. Portanto, reserve espaço de armazenamento equivalente a pelo menos o dobro do tamanho total da tabela source e de todos os seus índices.

    • Configurações de parâmetros do banco de dados: Este recurso depende do Logical Decoding. Defina o parâmetro wal_level como logical. Além disso, para executar várias tarefas de particionamento em paralelo, talvez seja necessário aumentar o valor do parâmetro max_worker_processes.

  • Requisitos de esquema de tabela e permissões

    • Chave primária ou identidade única: Como este recurso utiliza a replicação lógica nativa do PostgreSQL, a tabela source deve ter uma PRIMARY KEY ou a REPLICA IDENTITY configurada.

    • Permissões de usuário: A conta de usuário que executa a operação deve ter permissões para criar publication, subscription e replication slot. A conta também precisa de permissão para executar a operação RENAME nas tabelas source e de destino.

    • Consistência de permissões: Para garantir a continuidade dos negócios, conceda à conta de negócios as mesmas permissões na tabela particionada de destino que ela possui na tabela source antes da migração.

  • Tratamento de exceções e riscos

    • Operação não atômica: Este recurso é um processo via script e não possui atomicidade. Se uma exceção interromper o processo, objetos internos residuais poderão permanecer.

    • Limpeza manual: Caso ocorra uma exceção, limpe manualmente quaisquer registros remanescentes na tabela rds_online_migrate.internal_map, além de objetos de publication, subscription e replication slot. Consulte o log de erros e use os comandos a seguir para realizar a limpeza:

      -- Clean up metadata records
      DELETE FROM rds_online_migrate.internal_map WHERE src_relname = 'source_table' AND dst_relname = 'destination_table';
      
      -- Delete the residual publication
      DROP PUBLICATION publication_name;
      
      -- Delete the residual subscription
      DROP SUBSCRIPTION subscription_name;
      
      -- Delete the residual replication slot
      SELECT pg_drop_replication_slot('slot_name');
  • Impactos potenciais da operação RENAME

    • Reconstrução de objetos associados: Após a conclusão da operação RENAME, reconstrua manualmente quaisquer views, triggers e restrições de chave estrangeira dependentes da tabela original.

    • Impacto na replicação lógica: Se a tabela source fizer parte de outra tarefa de replicação lógica, a operação RENAME poderá interrompê-la. Após concluir a operação, adicione a nova tabela (a tabela de destino original) novamente à publication correspondente.

  • Cenário estendido

    • Este recurso também suporta o reparticionamento online de tabelas já particionadas.

Exemplo de uso

O exemplo a seguir demonstra como converter online uma tabela padrão chamada public.test em uma tabela particionada.

1. Configure os parâmetros do banco de dados

O recurso rds_online_migrate depende do Logical Decoding. No console do ApsaraDB RDS, defina o parâmetro wal_level como logical.

2. Prepare a tabela source e os dados

Crie uma tabela padrão chamada public.test para servir como tabela source da conversão. Em seguida, insira um milhão de linhas de dados de teste para simular um cenário real de negócios.

-- Create the source table
CREATE TABLE public.test(id int4 PRIMARY KEY, info text);

-- Insert test data
INSERT INTO public.test SELECT x, repeat(x::text, 2) FROM generate_series(1, 1000000) AS x;

3. Instale a extensão

Crie a extensão rds_online_migrate no banco de dados onde deseja executar a operação.

CREATE EXTENSION rds_online_migrate;

4. Crie a tabela particionada de destino

Crie uma tabela particionada de destino chamada public.test_p com a mesma estrutura da tabela source. Essa tabela de destino deve estar no mesmo esquema (namespace) da tabela source. Este exemplo cria uma tabela particionada por hash do ID, com quatro subpartições.

CREATE TABLE public.test_p (LIKE test INCLUDING ALL) PARTITION BY HASH(id);
CREATE TABLE public.test_p_0 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE public.test_p_1 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE public.test_p_2 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE public.test_p_3 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 3);

5. Execute a conversão online

Chame a função rds_online_migrate.rewrite_table para iniciar o particionamento online. O primeiro parâmetro da função é o nome da tabela source; o segundo, o nome da tabela particionada de destino. A função retorna t para indicar execução bem-sucedida.

SELECT rds_online_migrate.rewrite_table('public.test', 'public.test_p');
-- Expected output:
 rewrite_table
---------------
 t
(1 row)

6. Verifique o resultado da conversão

Após o sucesso da operação, a função alterna automaticamente os nomes das tabelas para garantir uma transição transparente aos negócios:

  • A tabela original public.test é renomeada para public.test_rds_bkp. Essa tabela serve como backup de dados para verificação posterior e pode ser excluída a seu critério.

  • A tabela particionada de destino public.test_p é renomeada para public.test e passa a ser usada como a nova tabela.

Em seguida, valide o resultado seguindo as etapas abaixo:

  • Verifique o esquema da tabela Use o comando \d para visualizar a lista de relações. Confirme se os nomes das tabelas foram alternados conforme esperado e se a nova tabela test é uma partitioned table.

    testdb=> \d
    -- Expected output:
                       List of relations
     Schema |     Name     |       Type        |   Owner
    --------+--------------+-------------------+-----------
     public | test         | partitioned table | rds_super
     public | test_p_0     | table             | rds_super
     public | test_p_1     | table             | rds_super
     public | test_p_2     | table             | rds_super
     public | test_p_3     | table             | rds_super
     public | test_rds_bkp | table             | rds_super
    (6 rows)
  • Valide a integridade dos dados Consulte o número de linhas na nova tabela, na tabela de backup e em cada partição para assegurar que a migração de dados está completa e distribuída corretamente.

    1. Consulte o número total de linhas na tabela de backup. A contagem deve ser igual à anterior à migração.

      SELECT count(*) FROM public.test_rds_bkp;
      -- Expected output: 1000000
    2. Consulte o número total de linhas na nova tabela particionada. A contagem deve corresponder à da tabela de backup.

      SELECT count(*) FROM public.test;
      -- Expected output: 1000000
    3. Consulte o número de linhas em cada partição para confirmar a distribuição dos dados nas tabelas filhas de acordo com a regra de hash.

      SELECT count(*) FROM public.test_p_0;
      -- Expected output: 249589
      SELECT count(*) FROM public.test_p_1;
      -- Expected output: 250376
      SELECT count(*) FROM public.test_p_2;
      -- Expected output: 249786
      SELECT count(*) FROM public.test_p_3;
      -- Expected output: 250249