Migrate a self-managed PostgreSQL database to a PolarDB for PostgreSQL cluster - Data Transmission Service: Central de Documentação do Alibaba Cloud

Por favor, escolha um tipo de migração

Selecione a combinação de tipos de migração adequada à sua situação:

Tipo de migração	O que faz	Tempo de inatividade	Custo	Recomendado quando
Migração de esquema + Migração de dados completa	Migra esquemas e dados históricos. A tarefa termina e é encerrada automaticamente.	Necessário — interrompa as gravações na origem antes da migração.	Grátis	O aplicativo pode tolerar uma janela de manutenção e a simplicidade é prioridade.
Migração de esquema + Migração de dados completa + Migração de dados incremental	Migra dados históricos e, em seguida, replica continuamente as alterações em andamento até o cutover.	Não é necessário — os serviços continuam em execução durante a migração.	Grátis nas fases de esquema e completa; cobrado na fase incremental.	A continuidade dos negócios é crítica e o aplicativo não pode tolerar tempo de inatividade.

Se executar apenas a migração completa: Interrompa as gravações no banco de dados de origem antes de iniciar. Os dados gravados na origem durante a migração não aparecerão no destino.

Pré-requisitos

Antes de começar, certifique-se de ter:

Um cluster PolarDB for PostgreSQL criado na Alibaba Cloud. Consulte Create a PolarDB for PostgreSQL cluster.
O armazenamento do cluster de destino deve ser maior que o espaço utilizado pelo banco de dados de origem.
Uma conta no banco de dados de origem com as permissões necessárias (consulte Permissões necessárias).

Para verificar as versões compatíveis dos bancos de dados de origem e destino, consulte

Overview of data migration scenarios

.

Permissões necessárias

Banco de dados	Migração de esquema	Migração de dados completa	Migração de dados incremental
PostgreSQL autogerenciado	USAGE em `pg_catalog`	SELECT nos objetos a serem migrados	Superusuário
PolarDB for PostgreSQL	Permissões de proprietário do esquema de destino	—	—

Por que o superusuário é necessário para a migração incremental: O DTS utiliza funções de replicação lógica do PostgreSQL para capturar alterações contínuas da origem. Essas funções são acessíveis apenas para superusuários. Sem permissões de superusuário no banco de dados de origem, não será possível iniciar a tarefa de migração incremental.

Para criar contas e conceder permissões:

PostgreSQL autogerenciado: consulte CREATE USER e GRANT na documentação do PostgreSQL.
PolarDB for PostgreSQL: consulte Create a database account e Manage databases.

Objetos compatíveis

Tabelas e esquemas

TABLE e SCHEMA, incluindo PRIMARY KEY, UNIQUE KEY, FOREIGN KEY, DATATYPE (tipo de dados nativo) e DEFAULT CONSTRAINT.

Outros objetos de banco de dados

VIEW, PROCEDURE (PostgreSQL V11 ou posterior), FUNCTION, RULE, SEQUENCE, EXTENSION, TRIGGER, AGGREGATE, INDEX, OPERATOR e DOMAIN.

Operações SQL compatíveis com a migração incremental

Tipo de operação	Instruções suportadas
DML	INSERT, UPDATE, DELETE
DDL	CREATE TABLE, DROP TABLE, ALTER TABLE (incluindo RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, ALTER COLUMN DROP DEFAULT), TRUNCATE TABLE (PostgreSQL V11 ou posterior), CREATE INDEX ON TABLE

Observações sobre a migração de DDL:

A migração de DDL está disponível apenas para tarefas criadas após 1º de outubro de 2020.
Tarefas criadas antes de 12 de maio de 2023 exigem um trigger e uma função no banco de dados de origem para capturar DDL. Consulte Use triggers and functions to implement incremental DDL migration for PostgreSQL databases.
A conta do banco de dados de origem deve ter privilégios administrativos para a migração de DDL.
O DTS não migra: modificadores CASCADE ou RESTRICT, DDL de sessões com SET session_replication_role = replica, DDL executado via chamadas de função, DDL misturado com DML na mesma submissão, instruções DDL fora do escopo da migração ou CREATE SEQUENCE.
Para usar uma tarefa de migração de dados criada antes de 12 de maio de 2023 para migrar operações DDL, crie um trigger e uma função no banco de dados de origem para capturar informações de DDL antes de configurar a tarefa. Para mais informações, consulte Use triggers and functions to implement incremental DDL migration for PostgreSQL databases.
A migração incremental não é compatível com dados do tipo BIT.

Faturamento

Tipo de migração	Taxa de configuração da instância	Taxa de tráfego de internet
Migração de esquema + Migração de dados completa	Grátis	Cobrado quando o Access Method de destino é Public IP Address. Consulte Billing overview.
Migração de dados incremental	Cobrado. Consulte Billing overview.	—

Observações de uso

Chaves estrangeiras e restrições

O DTS migra as foreign keys do banco de dados de origem durante a migração de esquema.
Durante as migrações completa e incremental, o DTS desativa temporariamente as verificações de restrição de foreign key e as operações em cascata no nível da sessão. Atualizações e exclusões em cascata na origem durante esse período podem causar inconsistência de dados.

Requisitos do banco de dados de origem

O servidor de origem deve ter largura de banda de saída suficiente; caso contrário, a velocidade de migração será afetada.
As tabelas devem ter uma chave primária ou restrição UNIQUE com valores de campo exclusivos. Sem isso, dados duplicados podem aparecer no destino.

Se a tabela de destino não foi criada pelo DTS (ou seja,

Schema Migration

não estiver selecionada), a tabela deve ter a mesma chave primária ou uma restrição UNIQUE não nula como a tabela de origem. Caso contrário, dados duplicados podem aparecer.
O nome do banco de dados de origem não pode conter hifens (-). Por exemplo, dts-testdata não é um nome válido.
A migração no nível de tabela com mapeamento de nomes de objetos aceita no máximo 1.000 tabelas por tarefa. Se exceder esse limite, divida as tabelas em várias tarefas ou migre o banco de dados inteiro.

Requisitos de write-ahead log (WAL) para migração incremental

Por favor, defina wal_level como logical.
Retenção de WAL: pelo menos 24 horas para tarefas apenas incrementais; pelo menos 7 dias para tarefas que incluem migração completa e incremental. Após a conclusão da migração completa, reduza a retenção para um período superior a 24 horas. Se o período de retenção for muito curto, o DTS não conseguirá recuperar os arquivos WAL necessários. Isso pode causar falha na tarefa, inconsistência de dados ou perda de dados. Problemas causados por retenção insuficiente não estão cobertos pelo Service Level Agreement (SLA) do DTS.
Se houver transações de longa duração no banco de dados de origem durante a migração incremental, os arquivos WAL gerados antes do commit dessas transações podem se acumular e esgotar o espaço em disco no servidor de origem.

Limites operacionais

Um switchover de primário/secundário no banco de dados PostgreSQL autogerenciado causa a falha da tarefa de migração.
Não execute operações DDL que alterem o esquema do banco de dados ou da tabela durante a migração completa de dados. A tarefa falhará.
Se um único registro a ser migrado do banco de dados de origem exceder 256 MB após uma alteração incremental, a instância de migração poderá falhar e não será possível recuperá-la. Nesse caso, reconfigure a instância de migração.
Uma atualização de versão principal (major version upgrade) do banco de dados de origem durante a execução de uma instância de migração causa a falha da instância, e não será possível recuperá-la.

Bancos de dados de origem do Google Cloud Platform

Se a origem for o Google Cloud Platform Cloud SQL for PostgreSQL, a Database Account deve ter permissões cloudsqlsuperuser, e a conta deve ter permissões de Owner em todos os objetos a serem migrados. Conceda permissões de Owner com:

GRANT <owner_of_the_object_to_be_migrated> TO <source_database_account>;

Uma conta com permissões cloudsqlsuperuser não gerencie dados de propriedade de outra conta cloudsqlsuperuser.

Requisito de REPLICA IDENTITY

Para migração incremental, execute o seguinte comando em cada tabela a ser migrada antes de gravar dados nela nestas duas situações:

Quando a instância de migração for executada pela primeira vez.
Quando a granularidade do objeto de migração for Schema e uma nova tabela for criada ou reconstruída com RENAME.

ALTER TABLE schema.table REPLICA IDENTITY FULL;

Substitua schema e table pelo nome real do esquema e da tabela. Execute este comando em horários de pico para evitar bloqueios de tabela. Se ignorar o item de pré-verificação relevante, o DTS executará esse comando automaticamente ao inicializar a instância.

Tipo de dado SERIAL

Se uma tabela contiver uma coluna SERIAL, o banco de dados de origem criará automaticamente uma Sequence para essa coluna. Se Schema Migration estiver selecionada, selecione também Sequence ou migre o esquema inteiro. Caso contrário, a instância de migração poderá falhar.

Parâmetro session_replication_role

Para migração completa ou incremental com foreign keys, triggers ou event triggers:

Se a conta de destino for uma conta privilegiada, o DTS define session_replication_role como replica no nível da sessão durante a migração.
Se a conta não tiver essa permissão, defina manualmente session_replication_role como replica no banco de dados de destino.

Enquanto este parâmetro estiver definido como replica, atualizações ou exclusões em cascata na origem podem causar inconsistência de dados. Após a conclusão da tarefa de migração do DTS, redefina session_replication_role para origin.

Tabelas temporárias e slot de replicação

O DTS cria as seguintes tabelas temporárias no banco de dados de origem para capturar instruções DDL, esquemas de tabela incrementais e dados de heartbeat. Por favor, não exclua essas tabelas durante a migração:

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 e public.aliyun_dts_instance.

Essas tabelas são excluídas automaticamente quando a instância do DTS é encerrada.

O DTS também cria um slot de replicação com o prefixo dts_sync_ no banco de dados de origem. Este slot retém logs incrementais dos últimos 15 minutos. Se a tarefa de migração for encerrada ou falhar, o DTS limpará o slot de replicação automaticamente. Se ocorrer um switchover de primário/secundário em uma instância do RDS for PostgreSQL, limpe manualmente o slot de replicação no banco de dados secundário.

Outras observações

Uma tarefa de migração migra dados de apenas um banco de dados. Para migrar vários bancos de dados, crie uma tarefa separada para cada um.
O DTS não é compatível com a migração de tabelas de extensão do TimescaleDB ou tabelas com relações de herança entre esquemas.
Execute a migração em horários fora do pico. A migração completa de dados utiliza recursos de leitura e gravação nos bancos de dados de origem e destino, aumentando a carga do servidor de banco de dados.
A migração completa de dados usa operações INSERT simultâneas, o que causa fragmentação de tabela no destino. Após a migração completa, o armazenamento da tabela de destino será maior que o armazenamento da tabela de origem.
Em colunas FLOAT ou DOUBLE, o DTS lê valores usando ROUND(COLUMN, PRECISION). A precisão padrão é de 38 dígitos para FLOAT e 308 dígitos para DOUBLE. Por favor, confirme se isso atende aos seus requisitos antes de iniciar.
O DTS tenta retomar tarefas com falha por até 7 dias. Antes de migrar o tráfego de negócios para a instância de destino, pare ou encerre a tarefa. Como alternativa, use o comando REVOKE para remover as permissões de gravação da conta do DTS no destino e evitar que os dados de origem sobrescrevam os dados de destino caso a tarefa seja retomada.
O DTS valida o conteúdo dos dados, mas não os metadados, como Sequences. Valide os metadados manualmente.
Após migrar o tráfego de negócios para o destino, os valores de sequence recém-gravados não continuarão a partir do valor máximo na origem. Por favor, atualize os valores de sequence no destino antes do switchover. Consulte Update the sequence value in the destination database.
Se uma instância de migração falhar, o suporte do DTS tentará a recuperação em até 8 horas. Durante a recuperação, o DTS pode reiniciar a instância ou ajustar os parâmetros da instância (os parâmetros do banco de dados não são modificados). Consulte Modify instance parameters.
Em tabelas particionadas, inclua a tabela pai e todas as partições filhas como objetos de migração. No PostgreSQL, a tabela pai não armazena dados diretamente — todos os dados estão nas partições filhas. A omissão de qualquer uma delas causa inconsistência de dados.

Preparar o banco de dados de origem

No caso de origens do Amazon RDS for PostgreSQL, consulte a seção

Before you begin

do tópico "Migrate incremental data from an Amazon RDS for PostgreSQL instance to an ApsaraDB RDS for PostgreSQL instance". No caso de origens do Amazon Aurora PostgreSQL, consulte

Preparation 1: Edit the inbound rule of the Amazon Aurora PostgreSQL instance

.

PostgreSQL 10.1 ou posterior

Por favor, acesse o servidor que hospeda o banco de dados PostgreSQL autogerenciado.
Por favor, edite postgresql.conf. Defina wal_level como logical e defina max_wal_senders e max_replication_slots com valores maiores que a soma do número de slots de replicação atualmente em uso mais o número de instâncias do DTS que usam este banco de dados como origem. Por exemplo, se houver atualmente 2 slots de replicação em uso e planejar executar 3 instâncias do DTS neste banco de dados, defina ambos os parâmetros com um valor maior que 5 (por exemplo, 10).

Reinicie o banco de dados PostgreSQL após modifique

postgresql.conf

para que as alterações entrem em vigor.
```
# - Settings -

wal_level = logical           # minimal, replica, or logical
                              # (change requires restart)

......

# - Sending Server(s) -

max_wal_senders = 10          # max number of walsender processes
                              # (change requires restart)
#wal_keep_segments = 0        # in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s     # in milliseconds; 0 disables

max_replication_slots = 10    # max number of replication slots
                              # (change requires restart)
```
Adicione os blocos CIDR do servidor DTS ao pg_hba.conf. Adicione apenas os blocos CIDR da região onde o banco de dados de destino está localizado. Consulte Add DTS server IP addresses to a whitelist.

Após modificar

pg_hba.conf

, execute

SELECT pg_reload_conf();

ou reinicie o banco de dados para que as alterações entrem em vigor. Se já tiver definido o endereço IP no

pg_hba.conf

como

0.0.0.0/0

, ignore esta etapa. Para obter detalhes sobre

pg_hba.conf

, consulte

The pg_hba.conf File

.
Crie o banco de dados e o esquema de destino no cluster de destino para corresponder aos objetos de origem que planeja migrar.

PostgreSQL 9.4.8 a 10.0

Baixe e instale o PostgreSQL a partir do código-fonte.
1. Baixe o código-fonte do PostgreSQL para a sua versão no PostgreSQL official website.
2. Execute os seguintes comandos para configurar, compilar e instalar:
Importante
- A versão do sistema operacional do PostgreSQL deve corresponder à versão do GNU Compiler Collection (GCC).
- Se sudo ./configure falhar com readline library not found. Use --without-readline to disable readline support., execute sudo ./configure --without-readline em vez disso.
- Se usar outro método de instalação, compile o plugin ali_decoding em um ambiente de teste com a mesma versão de sistema operacional e GCC.
```
sudo ./configure
sudo make
sudo make install
```

Baixe, compile e instale o plugin ali_decoding fornecido pelo DTS.

Copie os arquivos de saída para os diretórios necessários.

# contrib/ali_decoding/Makefile
MODULE_big = ali_decoding
MODULES = ali_decoding
OBJS    = ali_decoding.o

DATA = ali_decoding--0.0.1.sql ali_decoding--unpackaged--0.0.1.sql

EXTENSION = ali_decoding

NAME = ali_decoding

#subdir = contrib/ali_decoding
#top_builddir = ../..
#include $(top_builddir)/src/Makefile.global
#include $(top_srcdir)/contrib/contrib-global.mk

#PG_CONFIG = /usr/pgsql-9.6/bin/pg_config
#pgsql_lib_dir := $(shell $(PG_CONFIG) --libdir)
#PGXS := $(shell $(PG_CONFIG) --pgxs)
#include $(PGXS)

# Run the following commands to install the ali_decoding plug-in:
ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
else
subdir = contrib/ali_decoding
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif

sudo make
sudo make install

contrib目录

指定位置

Crie o banco de dados e o esquema de destino no cluster de destino para corresponder aos objetos de origem que planeja migrar.

Criar uma tarefa de migração

Etapa 1: Acessar a página Data Migration

Acesse o console do DTS.console do DTS
No painel de navegação à esquerda, clique em Data Migration.
No canto superior esquerdo, selecione a região onde a instância de migração será criada.

A navegação no console do DMS pode variar de acordo com o modo e o layout. Consulte Simple mode e Customize the layout and style of the DMS console.

Acesse o console do DMS.console do DMS
Na barra de navegação superior, passe o mouse sobre Data + AI > DTS (DTS) > Data Migration.
Na lista suspensa ao lado de Data Migration Tasks, selecione a região onde a instância de migração será criada.

Etapa 2: Configurar os bancos de dados de origem e de destino

Clique em Create Task.

Configure os bancos de dados de origem e de destino.

Aviso

Após selecionar as instâncias de origem e destino, revise os Limits exibidos na parte superior da página para evitar problemas de configuração da tarefa.

Banco de dados de origem (PostgreSQL autogerenciado no ecs)

Parâmetro	Descrição
Task Name	O DTS gera um nome automaticamente. Especifique um nome descritivo para identificar a tarefa. Os nomes das tarefas não precisam ser exclusivos.
Select Existing Connection	Selecione uma instância registrada na lista suspensa ou configure a conexão manualmente.
Database Type	Selecione PostgreSQL.
Access Method	Selecione o local de implantação do banco de dados de origem. Este exemplo usa Self-managed Database on ECS. Para outros métodos de acesso, consulte Preparations.
Instance Region	A região onde o banco de dados PostgreSQL de origem está localizado.
ECS Instance ID	O id da instância ecs que hospeda o banco de dados de origem (source).
Port Number	A porta do service. Padrão: 5432.
Database Name	O nome do banco de dados que contém os objetos a serem migrados.
Database Account	A conta do banco de dados de origem. Consulte Permissões necessárias.
Database Password	A senha da conta do banco de dados.
Encryption	Selecione Non-encrypted ou SSL-encrypted. Para SSL: faça o upload do CA Certificate (obrigatório) e, opcionalmente, do Client Certificate, Private Key of Client Certificate e Private Key Password of Client Certificate.

Banco de dados de destino (PolarDB for PostgreSQL)

Parâmetro	Descrição
Select Existing Connection	Selecione uma instância registrada na lista suspensa ou configure a conexão manualmente.
Database Type	Selecione PolarDB for PostgreSQL.
Access Method	Selecione Alibaba Cloud Instance.
Instance Region	A região onde o cluster PolarDB for PostgreSQL de destino está localizado.
Instance ID	O ID do cluster PolarDB for PostgreSQL de destino.
Database Name	O nome do banco de dados de destino que receberá os objetos migrados.
Database Account	A conta do banco de dados de destino. Consulte Permissões necessárias.
Database Password	A senha da conta do banco de dados.

Clique em Test Connectivity and Proceed.
- Adicione os blocos CIDR do servidor DTS às configurações de segurança dos bancos de dados de origem e destino. Consulte Add DTS server IP addresses to a whitelist.
- Se o banco de dados de origem ou destino for autogerenciado e o Access Method não for Alibaba Cloud Instance, clique em Test Connectivity na caixa de diálogo CIDR Blocks of DTS Servers.

Etapa 3: Selecionar objetos de migração e configurar opções avançadas

Na página Configure Objects, configure as definições de migração.

Se Schema Migration não estiver selecionada, crie o banco de dados e a tabela de destino no destino antes de iniciar e ative o mapeamento de nomes de objetos em Selected Objects.
Se uma tabela contiver uma coluna SERIAL e Schema Migration estiver selecionada, selecione também Sequence ou migre o esquema inteiro.

Parâmetro	Descrição
Migration Types	Selecione os tipos de migração para o seu cenário. Para obter detalhes, consulte Escolha um tipo de migração.
Processing Mode of Conflicting Tables	Precheck and Report Errors: falha na pré-verificação se a origem e o destino tiverem tabelas com nomes idênticos. Use o Map object names para resolver conflitos antes da migração. Ignore Errors and Proceed: ignora a verificação de conflitos. Durante a migração completa, o DTS mantém os registros existentes no destino. Durante a migração incremental, o DTS sobrescreve os registros de destino. Se os esquemas forem diferentes, apenas as colunas correspondentes serão migradas, ou a tarefa falhará.
Source Objects	Selecione esquemas ou tabelas para migrar. Clique no ícone de seta para adicioná-los aos Selected Objects. Se selecionar tabelas, o DTS não migrará views, triggers ou stored procedures.
Selected Objects	Clique com o botão direito em um objeto para renomeá-lo (consulte Map the name of a single object), defina condições de filtro WHERE ou selecione operações SQL para migrar. Clique em Batch Edit para renomear vários objetos de uma vez (consulte Map multiple object names at a time). Renomear um objeto pode causar falha na migração de objetos dependentes.

Clique em Next: Advanced Settings e configure as opções avançadas.

Parâmetro	Descrição
Dedicated Cluster for Task Scheduling	Por padrão, o DTS agenda tarefas para um cluster compartilhado. Para maior estabilidade, adquira um cluster dedicado. Consulte What is a DTS dedicated cluster.
Retry Time for Failed Connections	Tempo durante o qual o DTS tentará se reconectar em caso de falha de conexão. Intervalo: 10 a 1.440 minutos. Padrão: 720. Defina um valor superior a 30 minutos. Se a reconexão for bem-sucedida dentro desta janela, o DTS retoma a tarefa; caso contrário, a tarefa será interrompida. Se várias tarefas compartilharem a mesma origem ou destino, o valor definido mais recentemente será aplicado. A cobrança do DTS continua durante as tentativas de reconexão.
Retry Time for Other Issues	Tempo durante o qual o DTS tenta novamente em caso de falhas de DDL ou DML. Intervalo: 1 a 1.440 minutos. Padrão: 10. Defina um valor superior a 10 minutos. Deve ser menor que Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Limita a velocidade de migração completa para reduzir a carga na origem e no destino. Configure QPS (Queries Per Second) to the source database, RPS (Rows Per Second) of Full Data Migration e Data migration speed for full migration (MB/s). Disponível apenas quando Full Data Migration estiver selecionada.
Enable Throttling for Incremental Data Migration	Limita a velocidade de migração incremental. Configure RPS of Incremental Data Migration e Data migration speed for incremental migration (MB/s). Disponível apenas quando Incremental Data Migration estiver selecionada.
Environment Tag	Opcional. Adicione uma tag de ambiente à instância.
Configure ETL	Por favor, ative a extração, transformação e carga (ETL) para aplicar regras de processamento de dados durante a migração. Selecione Yesalert notification settings e insira instruções no editor de código. Consulte Configure ETL in a data migration or data synchronization task.
Monitoring and Alerting	Selecione Yes para receber alertas quando a tarefa falhar ou a latência de migração exceder um limiar. Configure os limiares de alerta e os contatos de notificação. Consulte Configure monitoring and alerting when you create a DTS task.

Clique em Next Step: Data Verification para configurar uma tarefa de verificação de dados. Consulte Configure a data verification task.

Etapa 4: Executar a pré-verificação e adquirir a instância

Clique em Next: Save Task Settings and Precheck.
- visualize os parâmetros da API e salve, passando o mouse sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters.
- O DTS executa uma pré-verificação antes de iniciar a tarefa de migração. A tarefa só iniciará após a aprovação na pré-verificação.
- Para itens de pré-verificação com falha, clique em View Details para ver a causa, solucionar o problema e executar a pré-verificação novamente.
- Para alertas de pré-verificação: se o alerta não puder ser ignorado, corrija o problema e execute a pré-verificação novamente. Se for possível ignorar o alerta, clique em Confirm Alert Details > Ignore > OK > Precheck Again. Ignorar alertas pode levar à inconsistência de dados.
Quando a Success Rate atingir 100%, clique em Next: Purchase Instance.

Na página Purchase Instance, configure a instância.

Parâmetro	Descrição
Resource Group	O grupo de recursos para a instância de migração. Padrão: default resource group. Consulte What is Resource Management?
Instance Class	A classe da instância determina a velocidade de migração. Selecione com base na sua carga de trabalho. Consulte Instance classes of data migration instances.

Marque a caixa de seleção Data Transmission Service (Pay-as-you-go) Service Terms.
Clique em Buy and Start e, em seguida, clique em OK na caixa de diálogo de confirmação.

Etapa 5: Monitorar o progresso da migração

Acesse a página Data Migration para monitorar a tarefa.

Apenas migração completa: a tarefa termina automaticamente quando concluída. O status exibe Completed.
Migração completa + incremental: a tarefa é executada continuamente. O status exibe Running. A migração incremental não termina até que você a encerre manualmente.

Verificar dados e realizar o cutover

Antes de migrar o tráfego de negócios para o cluster de destino, verifique a consistência dos dados e atualize as sequences.

Quando realizar o cutover (migração incremental)

Realize o cutover quando o banco de dados de origem não tiver novas gravações e a latência de migração atingir 0. Verifique o seguinte antes de realizar o cutover:

Verificação	Como verificar	Pronto quando
Nenhuma nova alteração de entrada	Monitore a latência da migração incremental no console do DTS	A latência atinge 0
Sequences atualizadas	Consulte Update the sequence value in the destination database	Os valores de sequence no destino estão atualizados

Etapas do cutover

Interrompa as gravações no banco de dados de origem.
Aguarde a latência da migração incremental atingir 0.
Atualize os valores de sequence no banco de dados de destino. Consulte Update the sequence value in the destination database.
Pare ou encerre a tarefa de migração do DTS para evitar que ela seja retomada e sobrescreva os dados de destino.
Altere a string de conexão do seu aplicativo para o cluster de destino.

Após o switchover do negócio, os valores de sequence recém-gravados não continuarão a partir do valor máximo no banco de dados de origem. Atualize os valores de sequence no destino antes de fazer o switchover.

Data Transmission Service:Migrar dados de um banco de dados PostgreSQL autogerenciado para um cluster PolarDB for PostgreSQL