Overview of upgrading an ApsaraDB RDS for PostgreSQL instance to a PolarDB for PostgreSQL cluster - PolarDB: Central de Documentação do Alibaba Cloud

O PolarDB permite atualizar uma instância do ApsaraDB RDS for PostgreSQL para um cluster do PolarDB for PostgreSQL mediante migração lógica com o Data Transmission Service (DTS). O cluster de destino herda as contas, os bancos de dados e as listas de permissões de endereços IP da instância de origem. O sistema suporta atualizações entre versões. Por exemplo, você pode atualizar uma instância do ApsaraDB RDS for PostgreSQL 11 para um cluster do PolarDB for PostgreSQL 14.

Como funciona a atualização

A atualização utiliza a migração lógica do DTS:

O DTS cria uma tarefa de sincronização de dados para migrar o esquema e todos os dados da instância de origem do ApsaraDB RDS for PostgreSQL para o cluster de destino do PolarDB for PostgreSQL.
O DTS sincroniza continuamente os dados incrementais para manter o cluster de destino atualizado.
Quando você estiver pronto para realizar a troca, o sistema redireciona o tráfego da instância de origem para o cluster de destino.

Benefícios

Benefício	Detalhe
Nenhuma alteração na aplicação	A troca substitui os endpoints entre a instância de origem e o cluster de destino. As aplicações se conectam ao PolarDB sem necessidade de atualizar as configurações de conexão.
Sem taxas de migração	A migração em si é gratuita. Você paga apenas pelo cluster do PolarDB de destino.
Sem perda de dados	Todos os dados são totalmente sincronizados antes da troca.
Tempo de inatividade mínimo	A sincronização de dados incrementais mantém o tempo de inatividade do serviço abaixo de 10 minutos.
Migração a quente	Ocorre apenas uma desconexão transitória no momento em que o tráfego é transferido da instância de origem para o cluster de destino.
Suporte a rollback	Se uma migração falhar, faça o rollback em até 10 minutos.

Pré-requisitos

Antes de iniciar uma atualização, verifique se as seguintes condições foram atendidas:

A versão da instância de origem do ApsaraDB RDS for PostgreSQL deve ser igual ou anterior à versão do cluster de destino do PolarDB for PostgreSQL. Não há suporte para downgrade. Por exemplo, não é possível atualizar uma instância do ApsaraDB RDS for PostgreSQL 14 para um cluster do PolarDB for PostgreSQL 11.
A instância de origem não possui triggers. Caso exista algum trigger, exclua-o e clique em Continue, ou clique em Cancel e crie manualmente uma tarefa de sincronização de dados do DTS. Para mais informações, consulte Synchronize data from an ApsaraDB RDS for PostgreSQL instance to a PolarDB for PostgreSQL cluster.
Tanto o SSL quanto a criptografia transparente de dados (TDE) devem estar desativados nos endpoints da instância de origem. Instâncias com SSL ou TDE ativados não podem ser atualizadas.
A instância de origem do ApsaraDB RDS for PostgreSQL também precisa atender às condições abaixo. Se alguma condição não for atendida, ela será exibida na página de atualização do PolarDB:
- Existem bancos de dados na instância de origem do ApsaraDB RDS for PostgreSQL.
- Os nomes das contas na instância de origem usam formatos compatíveis com o PolarDB for PostgreSQL.
- A função vinculada ao serviço AliyunServiceRoleForPolarDB foi criada.
- Os valores de max_replication_slots e max_wal_senders excedem individualmente o número total de links bidirecionais do DTS necessários, que corresponde à quantidade de bancos de dados na instância.
- A instância não tem mais de 30 bancos de dados. É possível criar até 30 links bidirecionais do DTS.
- O parâmetro de kernel wal_level está definido como logical.

Limitações

Limitações gerais

Não há suporte para migração entre regiões.
Os parâmetros da instância de origem não podem ser alterados durante a migração.
Durante a migração, o DTS cria automaticamente uma conta no cluster de destino com um nome no formato dts_clone% e uma senha gerada aleatoriamente. Não altere nem exclua essa conta até que a migração seja concluída.

Requisitos da instância de origem

As tabelas que você deseja sincronizar devem ter uma restrição PRIMARY KEY ou UNIQUE com todos os campos únicos. Sem isso, o banco de dados de destino poderá conter registros duplicados.

Se você selecionar tabelas individuais como escopo de sincronização e precisar renomeá-las ou renomear suas colunas no destino, uma única tarefa pode sincronizar até 5.000 tabelas. Para mais de 5.000 tabelas, configure várias tarefas ou sincronize todo o banco de dados.

Requisitos de write-ahead logging (WAL):

Tipo de sincronização	Requisito de retenção de WAL
Apenas sincronização incremental	Mais de 24 horas
Sincronização completa + incremental	Pelo menos 7 dias

Após a conclusão da sincronização completa dos dados, você pode reduzir o período de retenção para mais de 24 horas.

Não modifique os endpoints ou a zona da instância de origem durante a sincronização. Essa ação causa falha na tarefa de sincronização.

Transações de longa duração podem causar acúmulo de logs WAL no banco de dados de origem e esgotar o espaço em disco.

Suporte a instruções SQL

DML: Há suporte para INSERT, UPDATE e DELETE.

DDL: As seguintes instruções DDL são suportadas se você usar uma conta privilegiada na instância de origem e a instância executar a versão secundária do mecanismo 20210228 ou posterior. Para obter informações sobre como atualizar a versão secundária do mecanismo, consulte Update the minor engine version.

CREATE TABLE e DROP TABLE
ALTER TABLE (incluindo RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK e ALTER COLUMN DROP DEFAULT)
TRUNCATE TABLE (a instância de origem executa PostgreSQL 11 ou posterior)
CREATE INDEX ON TABLE

Instruções DDL não sincronizadas:

Instruções DDL contendo CASCADE ou RESTRICT
Instruções DDL de sessões que executaram SET session_replication_role = replica
Instruções DDL confirmadas na mesma transação que instruções DML
Instruções DDL para objetos fora do escopo de sincronização

Outras limitações

Cada tarefa de sincronização de dados sincroniza apenas um banco de dados. Para vários bancos de dados, crie uma tarefa separada para cada um.
Se você criar uma tabela ou usar RENAME durante a sincronização no nível de esquema, execute a seguinte instrução antes de gravar dados nessa tabela. Execute essa operação fora do horário de pico e sem bloquear a tabela para evitar deadlocks.
```
ALTER TABLE schema.table REPLICA IDENTITY FULL;
```
Substitua schema e table pelo nome real do esquema e pelo nome da tabela.
O DTS cria as seguintes tabelas temporárias no banco de dados de origem. Não as exclua durante a sincronização, pois elas são removidas automaticamente após a liberação da instância do DTS: public.dts_pg_class, public.dts_pg_attribute, public.dts_pg_type, public.dts_pg_enum, public.dts_postgres_heartbeat, public.dts_ddl_command, public.dts_args_session
O DTS adiciona uma tabela de heartbeat chamada dts_postgres_heartbeat ao banco de dados de origem para manter a precisão da latência de sincronização.
O DTS cria um slot de replicação com o prefixo dts_sync_ no banco de dados de origem. Os slots de replicação históricos são limpos automaticamente a cada 120 minutos.

O DTS exclui automaticamente o slot de replicação quando a instância é liberada. Se você alterar a senha do banco de dados ou excluir as entradas da lista de permissões de IP do DTS durante a sincronização, o slot de replicação não poderá ser excluído automaticamente. Nesse caso, exclua-o manualmente do banco de dados de origem para evitar acúmulo de armazenamento e possível indisponibilidade da instância de origem. Se a tarefa de sincronização for liberada ou falhar, o DTS limpará o slot de replicação automaticamente. Após um failover primário/secundário no banco de dados PostgreSQL de origem, faça login no banco de dados secundário para limpar o slot de replicação manualmente.
Durante a sincronização completa de dados, operações INSERT simultâneas causam fragmentação nas tabelas do banco de dados de destino. Após a conclusão da sincronização completa dos dados, o tablespace do banco de dados de destino será maior que o do banco de dados de origem.
Para sincronização de dados no nível de tabela, se os dados forem gravados no banco de dados de destino apenas por meio do DTS, você poderá usar o Data Management (DMS) para executar operações DDL online. Para mais informações, consulte Perform lock-free DDL operations.
Grave dados no banco de dados de destino apenas por meio do DTS durante a migração. Gravar por meio de outras ferramentas gera risco de inconsistência de dados e possível perda de dados caso você execute posteriormente operações DDL online pelo Data Management (DMS).
O DTS não valida metadados como sequences. Verifique a validade das sequences manualmente.

Após transferir as cargas de trabalho para o cluster de destino, os novos valores de sequence não continuam automaticamente a partir do valor máximo da origem. Antes da troca, consulte os valores máximos das sequences na origem e defina-os como valores iniciais no destino. Use a seguinte instrução para consultar os valores máximos das sequences:

do language plpgsql $$
declare
  nsp name;
  rel name;
  val int8;
begin
  for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
  loop
    execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
    raise notice '%',
    format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
  end loop;
end;
$$;

Faturamento

O recurso de atualização está atualmente em fase de teste gratuito. Nenhuma taxa é cobrada pelas tarefas de sincronização durante esse período.

Tipo de sincronização	Regra de faturamento
Sincronização de esquema e sincronização completa de dados	Gratuito por 30 dias após a criação da tarefa. Após 30 dias, a tarefa é cancelada automaticamente sem cobranças.
Sincronização incremental de dados

Você é cobrado pelo cluster do PolarDB de destino independentemente do status de teste gratuito das tarefas de sincronização.

Para verificar o período de validade restante de uma tarefa de sincronização, acesse o console do PolarDB, abra a página Basic Information do seu cluster e localize a seção RDS Migration.

Descrição da política de backup

O ciclo de backup regular e o horário de início do backup do PolarDB permanecem consistentes com o ciclo de backup regular e o horário de início do backup do RDS.
A relação correspondente entre a duração de retenção de backup do RDS e do PolarDB é a seguinte:
- Se a duração de retenção de backup do RDS for menor ou igual a 14 dias, a duração de retenção de backup de nível 1 do PolarDB será igual à duração de retenção de backup do RDS.
- Se a duração de retenção de backup do RDS for maior que 14 dias e menor que 30 dias, a duração de retenção de backup de nível 1 do PolarDB será fixada em 14 dias, o backup de nível 2 será ativado e a duração de retenção de backup de nível 2 do PolarDB na mesma região será fixada em 30 dias. Se a duração de retenção de backup do RDS for maior que 30 dias, o backup de nível 2 do PolarDB será ativado e a duração de retenção de backup de nível 2 na mesma região será igual à duração de retenção de backup do RDS.
- Se o backup do RDS tiver retenção permanente, a duração de retenção de backup de nível 1 do PolarDB será fixada em 14 dias, o backup de nível 2 será ativado e os backups terão retenção permanente.
Se o backup de alta frequência estiver ativado no RDS, o backup de alta frequência será ativado por padrão no PolarDB. As frequências correspondentes de backup de alta frequência entre o RDS e o PolarDB são as seguintes:
- Se a frequência de backup de alta frequência do RDS for menor ou igual a 120 minutos, a frequência de backup de alta frequência do PolarDB será fixada em 120 minutos.
- Se a frequência de backup de alta frequência do RDS for maior que 120 minutos e menor ou igual a 180 minutos, a frequência de backup de alta frequência do PolarDB será fixada em 180 minutos.
- Se a frequência de backup do RDS for outra frequência, a frequência de backup de alta frequência do PolarDB será fixada em 240 minutos.

Após a conclusão da migração, você pode modificar a política de backup no console conforme necessário.

Troca com endpoints

Ao atualizar, selecione Switch with Endpoints (Connection Changes Not Required) para trocar os endpoints entre a instância de origem do ApsaraDB RDS for PostgreSQL e o cluster de destino do PolarDB. As aplicações se conectam ao cluster do PolarDB sem nenhuma alteração de configuração.

Antes de usar essa opção, observe o seguinte:

Apenas os endpoints são trocados. vSwitches e endereços IP virtuais não são trocados.
A troca de endpoints exige que tanto a instância de origem quanto o cluster de destino possuam os tipos de endpoint correspondentes. Por padrão, apenas endpoints primários na rede interna podem ser trocados.
Os endpoints primários são sempre trocados. Você também pode optar por trocar:
- Endpoints de proxy dedicado (origem) por endpoints de cluster padrão (destino)
- Endpoints somente leitura (origem) por endpoints personalizados (destino)
Um cluster do PolarDB suporta até 7 endpoints de cluster. Portanto, até 7 endpoints de proxy dedicado ou somente leitura da instância de origem podem ser trocados.
Se você precisar de endpoints que ainda não existem, crie-os antes da troca. Para endpoints de cluster do PolarDB, consulte View or apply for an endpoint. Para endpoints do ApsaraDB RDS for PostgreSQL, consulte Configure endpoints for an RDS instance.
As portas não são trocadas. Certifique-se de que as portas de origem e destino correspondam, exceto para portas de endpoints personalizados. Para modificar uma porta, consulte View and manage instance endpoints and ports.
Após a troca de endpoints, a expiração do cache DNS pode causar temporariamente falhas de conexão ou conexões somente leitura ao cluster do PolarDB. Limpe o cache DNS no seu servidor para resolver isso.
Após a troca de endpoints, use a versão mais recente do DMS e o ID do cluster (não o endpoint) para fazer login no banco de dados do PolarDB.