Todos os produtos
Search
Central de documentação

Data Transmission Service:Migrar MySQL autogerenciado para o RDS for MySQL

Última atualização: Oct 14, 2026

O Data Transmission service (DTS) migra dados de um banco de dados MySQL local, em uma instância ECS ou em uma plataforma de nuvem de terceiros para uma instância ApsaraDB RDS for MySQL sem tempo de inatividade. O DTS oferece suporte à migração de schema, migração completa de dados e migração incremental de dados. Combine esses tipos para concluir a migração sem interromper a aplicação.

Pré-requisitos

Precauções

Nota
  • O DTS migra chaves estrangeiras durante a migração de schema.

  • Durante a migração completa e incremental de dados, o DTS desativa temporariamente as verificações de restrição e cascatas de chave estrangeira no nível da sessão. Atualizações ou exclusões em cascata no banco de dados de origem enquanto a tarefa está em execução podem causar inconsistência de dados.

  • O DTS não suporta a execução de migração completa em múltiplas etapas; a migração completa deve ser concluída em uma única operação. Se você precisar migrar dados em lotes, configure várias tarefas de migração.

Tipo

Descrição

Limites do banco de dados de origem

  • Requisito de largura de banda: O servidor que hospeda o banco de dados de origem deve ter largura de banda de saída suficiente. Caso contrário, a velocidade de migração será reduzida.

  • Cada tabela a ser migrada deve ter uma chave primária ou restrição UNIQUE, e as colunas de chave devem conter valores exclusivos. Caso contrário, registros duplicados podem aparecer no banco de dados de destino.

  • Se você selecionar tabelas como objetos de migração e editá-las — por exemplo, mapeando nomes de colunas — uma única tarefa de migração suporta até 1.000 tabelas. Se você exceder esse limite, a tarefa falhará com um erro no envio. Para corrigir isso, divida as tabelas em várias tarefas ou configure uma tarefa de migração de banco de dados completo.

  • Se você precisar de migração incremental, ative o log binário:

    • Defina binlog_format como ROW e binlog_row_image como FULL. Caso contrário, a pré-verificação falhará e a tarefa não poderá ser iniciada.

      Importante

      Se a sua origem MySQL autogerenciada for um cluster dual-master — onde cada instância atua como master e slave — ative o parâmetro log_slave_updates. Isso garante que o DTS possa ler todos os logs binários.

    • Para instâncias RDS for MySQL, retenha logs binários locais por pelo menos três dias (recomenda-se sete dias). Para bancos de dados MySQL autogerenciados, retenha logs binários locais por pelo menos sete dias. Se o DTS não conseguir acessar os logs binários, a tarefa falhará. Em casos extremos, pode ocorrer inconsistência ou perda de dados. Problemas causados por períodos de retenção de log binário menores do que o exigido pelo DTS não são cobertos pelo SLA do DTS.

      Nota

      Para definir o retention period para logs binários locais em uma instância RDS for MySQL, consulte Automatically delete local logs.

  • Operações não permitidas no banco de dados de origem:

    • Não execute operações DDL que alterem schemas de banco de dados ou tabelas durante a migração de schema ou a migração completa. Caso contrário, a tarefa de migração falhará.

      Nota

      Durante a migração completa, o DTS consulta o banco de dados de origem. Isso cria bloqueios de metadados que podem impedir operações DDL no banco de dados de origem.

    • Se você executar apenas a migração completa, não grave novos dados na instância de origem. Caso contrário, os dados de origem e destino ficarão inconsistentes. Para manter os dados consistentes em tempo real, selecione migração de schema, migração completa e migração incremental.

  • O DTS não migra dados gerados por alterações que não gravam em logs binários. Exemplos incluem dados restaurados de backups físicos ou criados por operações em cascata.

    Nota

    Se isso ocorrer, execute a migração completa novamente quando a sua aplicação permitir.

  • Se o seu banco de dados MySQL de origem for da versão 8.0.23 ou posterior e contiver colunas ocultas, o DTS não conseguirá ler essas colunas. Isso pode causar perda de dados.

    Nota

    Execute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; para tornar a coluna oculta visível. Para mais informações, consulte Invisible Columns.

  • Compatibilidade com MySQL: Quando o DTS migra dados de um banco de dados de origem da família MySQL, ele depende do protocolo padrão MySQL e do formato Binlog, e comportamentos incompatíveis com o MySQL padrão não são suportados. Se o seu banco de dados de origem apresenta compatibilidade com MySQL, mas se comporta de maneira diferente do MySQL (por exemplo, quando o OceanBase é conectado como origem no modo MySQL, o timestamp do evento rotate final no Binlog é 0, o que difere do MySQL), a tarefa de migração do DTS pode falhar.

Outros limites

  • Recomendamos o uso da mesma versão do MySQL para os bancos de dados de origem e destino para garantir compatibilidade.

  • Se o seu banco de dados de origem usar operações DDL online no modo de tabela temporária — incluindo cenários de mesclagem de várias tabelas — ou adicionar índices baseados em funções a colunas de chave exclusiva, pode ocorrer perda de dados ou falha de tarefa no banco de dados de destino.

  • O DTS não suporta a migração de parsers definidos usando sintaxe de comentário.

  • Se ocorrer um conflito de chave primária ou chave exclusiva durante a migração:

    • Se os schemas das tabelas forem consistentes e um registro no banco de dados de destino tiver o mesmo valor de chave primária que um registro no banco de dados de origem:

      • Durante a migração completa, o DTS mantém o registro no banco de dados de destino. O registro do banco de dados de origem não é migrado.

      • Durante a migração incremental, o DTS não mantém o registro no banco de dados de destino. O registro do banco de dados de origem sobrescreve o registro no banco de dados de destino.

    • Se os schemas das tabelas forem inconsistentes, apenas algumas colunas de dados podem ser migradas, ou a migração pode falhar. Prossiga com cautela.

  • Se o seu banco de dados MySQL de destino for da versão 8.0.23 ou posterior e a coluna de destino for uma coluna oculta, o DTS não poderá gravar dados nela. Isso pode causar falha na tarefa ou perda de dados.

    Nota

    Execute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; para tornar a coluna oculta visível. Para mais informações, consulte Invisible Columns.

  • Se você não usar o DTS para migrar schemas, verifique manualmente a compatibilidade dos campos. Caso contrário, a tarefa pode falhar ou pode haver perda de dados. Por exemplo, se o tipo da coluna de origem for text e o tipo da coluna de destino for varchar(255), campos grandes na origem podem ser truncados.

  • Se seus dados incluírem caracteres de quatro bytes — como caracteres chineses raros ou emojis — o banco de dados e a tabela de destino devem usar o charset utf8mb4.

    Nota

    Se você usar o DTS para migrar schemas, defina o parâmetro de nível de instância character_set_server como utf8mb4 no banco de dados de destino.

  • Antes da migração, avalie o desempenho dos bancos de dados de origem e destino. Execute a migração durante horários de baixa demanda. Caso contrário, a migração completa consumirá recursos de leitura e gravação em ambos os bancos de dados e aumentará a carga do banco de dados.

  • A migração completa executa operações INSERT concorrentemente. Isso fragmenta as tabelas de destino. Após a migração completa, as tabelas de destino exigirão mais espaço de armazenamento do que as tabelas de origem.

  • Confirme se a precisão de migração do DTS para colunas FLOAT ou DOUBLE atende às suas necessidades de negócios. O DTS lê essas colunas usando ROUND(COLUMN,PRECISION). Se nenhuma precisão for definida, o DTS usará 38 dígitos para FLOAT e 308 dígitos para DOUBLE.

  • O DTS tenta recuperar tarefas com falha em até sete dias. Antes de alternar o tráfego para a instância de destino, encerre ou libere a tarefa. Ou execute o comando revoke para remover a permissão de gravação do DTS na conta da instância de destino. Isso impede que a recuperação automática sobrescreva os dados de destino com os dados de origem.

  • Se as gravações DDL falharem no banco de dados de destino, a tarefa do DTS continuará em execução. Verifique os comandos DDL com falha nos logs da tarefa. Para instruções, consulte View task logs.

  • Se você gravar colunas com nomes idênticos, mas com maiúsculas e minúsculas diferentes, na mesma tabela no banco de dados MySQL de destino, podem ocorrer resultados inesperados. Os nomes de colunas do MySQL não diferenciam maiúsculas e minúsculas.

  • Após a conclusão da migração — o status da tarefa é Status e o status muda para Completed — execute analyze table <table_name> para confirmar se todos os dados foram gravados na tabela de destino. Por exemplo, após um failover de alta disponibilidade (HA) no banco de dados MySQL de destino, os dados podem permanecer na memória e nunca chegar ao disco, causando perda de dados.

  • Se a sua instância RDS for MySQL tiver o Always-Encrypted ativado, não há suporte para migração completa.

    Nota

    Instâncias RDS for MySQL com Transparent Data Encryption (TDE) ativado suportam migração de schema, migração completa e migração incremental.

  • Para migrar contas de banco de dados da origem, atenda aos pré-requisitos necessários e revise as considerações relacionadas. Para mais informações, consulte Migrate database accounts.

  • Se uma tarefa falhar, a equipe de suporte do DTS tentará restaurá-la em até oito horas. Durante a restauração, eles podem reiniciar a tarefa ou ajustar seus parâmetros.

    Nota

    Apenas os parâmetros da tarefa do DTS são modificados — não os parâmetros do banco de dados. Os parâmetros que podem ser ajustados incluem aqueles listados em Modify instance parameters.

Casos especiais

  • Para origens MySQL autogerenciadas:

    • Um failover master-standby no banco de dados de origem causa a falha da tarefa de migração.

    • O DTS calcula a latência comparando o timestamp do último registro migrado para o banco de dados de destino com a hora atual. Se nenhuma operação DML for executada na origem por muito tempo, a latência reportada se torna imprecisa. Se a latência parecer muito alta, execute uma operação DML na origem e atualize o valor da latência.

      Nota

      Se você selecionar a migração de banco de dados completo, crie uma tabela de heartbeat. Atualize ou grave nela a cada segundo.

    • O DTS executa periodicamente CREATE DATABASE IF NOT EXISTS test no banco de dados de origem para avançar o offset do log binário.

    • Se a sua origem for Amazon Aurora MySQL ou outra instância MySQL em cluster, garanta que o nome de domínio ou endereço IP configurado para a tarefa — e sua resolução dns — sempre aponte para um nó de leitura e gravação (RW). Caso contrário, a tarefa de migração pode falhar.

  • Para origens RDS for MySQL:

    • Se você precisar de migração incremental, não há suporte para instâncias RDS for MySQL que não gravam logs de transações — como instâncias somente leitura do RDS for MySQL 5.6 — como origens.

    • O DTS executa periodicamente CREATE DATABASE IF NOT EXISTS test no banco de dados de origem para avançar o offset do log binário.

  • Para destinos RDS for MySQL:

    O DTS cria bancos de dados automaticamente no RDS for MySQL. Se o nome do banco de dados não estiver em conformidade com as regras de nomenclatura do RDS for MySQL, crie o banco de dados manualmente antes de configurar a tarefa de migração. Para instruções, consulte Manage databases.

Faturamento

Tipo de migração

Taxa de configuração da instância

Taxa de tráfego de internet

Migração de schema e migração completa de dados

Gratuito.

Quando o parâmetro Access Method do banco de dados de destino é definido como Public IP Address, há cobrança de tráfego de internet. Para mais informações, consulte Billing overview.

Migração incremental de dados

Há cobrança. Para mais informações, consulte Billing overview.

Tipos de migração

  • Migração de schema

    O Data Transmission Service (DTS) migra as definições de schema dos objetos de migração do banco de dados de origem para o banco de dados de destino.

    • O DTS suporta migração de schema para tabelas, views, triggers, stored procedures e functions.

      Nota

      O routine_body das stored procedures, o routine_body das functions e o select_statement das views não são modificados.

    • Durante a migração de schema, o DTS altera o DEFINER para INVOKER nas views, stored procedures e functions a serem migradas. Essa ação altera o valor de SQL SECURITY para INVOKER. O DTS também define o DEFINER como a conta do banco de dados de destino usada para a tarefa de migração.

      Nota

      O método de autenticação de segurança e o definer do banco de dados de origem não são modificados.

    • O DTS não migra as informações de conta e permissão (informações USER) do banco de dados de origem. O DTS também altera o método de autenticação de segurança das views, stored procedures e functions a serem migradas para INVOKER. Portanto, ao chamar esses objetos no banco de dados de destino, o invocador deve ter permissões de leitura e gravação no banco de dados de destino. Caso contrário, a chamada falhará devido a permissões insuficientes. Se a conta do invocador já tiver permissões de leitura e gravação no banco de dados de destino, a chamada desses objetos não será afetada. Se você quiser que o DEFINER de um objeto no banco de dados de destino seja idêntico ao do banco de dados de origem, exclua o objeto que apresenta falha ao ser chamado no banco de dados de destino e recrie-o. Ao recriar o objeto, especifique o DEFINER original na instrução de criação e certifique-se de que a conta definer exista no banco de dados de destino.

  • Migração completa

    O DTS migra todos os dados históricos dos objetos de migração especificados do banco de dados de origem para o banco de dados de destino.

  • Migração incremental

    Após a conclusão de uma migração completa, o DTS migra atualizações incrementais de dados do banco de dados de origem para o banco de dados de destino. A migração incremental permite migrar dados de forma contínua, sem interromper suas aplicações autogerenciadas.

Operações SQL para migração incremental

Tipo de operação

Instrução SQL

DML

INSERT, UPDATE, DELETE

DDL

  • ALTER TABLE, ALTER VIEW

  • CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW

  • DROP INDEX, DROP TABLE

  • RENAME TABLE

    Importante

    Uma operação RENAME TABLE pode causar inconsistência de dados. Por exemplo, se você selecionar apenas uma tabela como objeto de migração e renomear a tabela na instância de origem durante a migração, os dados dessa tabela não serão migrados para o banco de dados de destino. Para evitar esse problema, selecione o banco de dados inteiro ao qual a tabela pertence como objeto de migração ao configurar a tarefa de migração de dados. Certifique-se de que os bancos de dados aos quais a tabela pertence antes e depois da operação RENAME TABLE estejam incluídos nos objetos de migração.

  • TRUNCATE TABLE

Permissões necessárias para contas de banco de dados

Banco de dados

Migração de schema

Migração completa

Migração incremental

Banco de dados MySQL autogerenciado

Permissão SELECT

Permissão SELECT

  • Permissão SELECT nos objetos a serem migrados.

  • Permissões REPLICATION CLIENT, REPLICATION SLAVE e SHOW VIEW.

  • Permissão CREATE, que permite ao DTS criar um banco de dados chamado test para avançar a posição do log binário.

Instância ApsaraDB RDS for MySQL

Permissões de leitura e gravação

Para criar e autorizar uma conta de banco de dados:

Nota

Para migrar informações de conta, a conta da tarefa de migração requer permissões adicionais. Migrate database accounts.

Procedimento

  1. Acesse a página da lista de tarefas de migração para a região de destino usando um dos seguintes métodos.

    No console do DTS

    1. Faça login no Data Transmission Service (DTS) console.

    2. No painel de navegação à esquerda, clique em Data Migration.

    3. No canto superior esquerdo da página, selecione a região onde a instância de migração está localizada.

    No console do DMS

    Nota

    As operações podem variar dependendo do modo e do layout do console do DMS. Para mais informações, consulte Simple mode console e Customize the layout and style of the DMS console.

    1. Faça login no Data Management (DMS) console.

    2. Na barra de menu superior, escolha Data + AI > Data Transmission (DTS) > Data Migration.

    3. À direita de Data Migration Tasks, selecione a região onde a instância de migração está localizada.

  2. Clique em Create Task e acesse a página de configuração da tarefa.

  3. Configure os bancos de dados de origem e destino.

    Aviso

    Após selecionar as instâncias de origem e destino, leia atentamente os limites exibidos na parte superior da página. Caso contrário, a tarefa pode falhar ou pode ocorrer inconsistência de dados.

    Seção

    Parâmetro

    Descrição

    N/A

    Task Name

    O DTS gera automaticamente um nome de tarefa. Especifique um nome descritivo para facilitar a identificação. O nome não precisa ser exclusivo.

    Source Database

    Select Existing Connection

    Não é necessária uma conexão existente. Configure as informações do banco de dados abaixo.

    Database Type

    Selecione MySQL.

    Access Method

    Selecione um método de acesso para o seu banco de dados de origem. Este exemplo usa Public IP Address.

    Nota

    Se o seu banco de dados de origem for autogerenciado, você também deve concluir os preparations necessários.

    Instance Region

    Selecione a região do banco de dados MySQL de origem.

    Domain Name or IP

    Insira o endpoint do banco de dados MySQL de origem. Este exemplo usa um endpoint público.

    Port Number

    Insira a porta de serviço do banco de dados MySQL de origem. A porta deve estar acessível pela internet. Padrão: 3306.

    Database Account

    Insira a conta para o banco de dados MySQL de origem. Permissões necessárias: Permissions required for database accounts.

    Database Password

    Insira a senha da conta do banco de dados.

    Encryption

    Selecione Non-encrypted ou SSL-encrypted conforme necessário.

    • Se a criptografia SSL não estiver ativada para o banco de dados MySQL autogerenciado, selecione Non-encrypted.

    • Se a criptografia SSL estiver ativada para o banco de dados MySQL autogerenciado, selecione SSL-encrypted. Você também precisa fazer o upload de um CA Certificate e insira a CA Certificate Password.

    Destination Database

    Select Existing Connection

    Não é necessária uma conexão existente. Configure as informações do banco de dados abaixo.

    Database Type

    Selecione MySQL.

    Access Method

    Selecione Alibaba Cloud Instance.

    Instance Region

    Selecione a região da instância ApsaraDB RDS for MySQL de destino.

    Replicate Data Across Alibaba Cloud Accounts

    Este exemplo usa a mesma conta Alibaba Cloud. Selecione No.

    RDS Instance ID

    Selecione o ID da instância ApsaraDB RDS for MySQL de destino.

    Database Account

    Insira a conta do banco de dados da instância ApsaraDB RDS for MySQL de destino. Permissões necessárias: Permissions required for database accounts.

    Database Password

    Insira a senha da conta do banco de dados.

    Encryption

    Selecione Non-encrypted ou SSL-encrypted com base nos requisitos do seu banco de dados. Se você definir este parâmetro como SSL-encrypted, deverá ativar a criptografia SSL para a instância RDS for MySQL previamente. Para mais informações, consulte Quickly enable SSL encryption using a cloud certificate.

  4. Após concluir a configuração, clique em Test Connectivity and Proceed na parte inferior da página. Na caixa de diálogo CIDR Blocks of DTS Servers que aparece, clique em Test Connectivity.

    Nota

    Certifique-se de que os segmentos de endereço IP do serviço DTS sejam adicionados automática ou manualmente às configurações de segurança dos bancos de dados de origem e destino para permitir o acesso dos servidores DTS. Para mais informações, consulte Add DTS server IP addresses to a whitelist.

  5. Configure os objetos da tarefa.

    1. Na página Configure Objects, configure os objetos que deseja migrar.

      Parâmetro

      Descrição

      Migration Types

      • Para realizar apenas a migração completa, selecione Schema Migration e Full Data Migration.

      • Para realizar uma migração sem tempo de inatividade, selecione Schema Migration, Full Data Migration e Incremental Data Migration.

      Nota
      • Se você não selecionar Schema Migration, garanta que existam um banco de dados e tabelas para receber os dados no banco de dados de destino. Você também pode usar o recurso de mapeamento de nome de objeto na caixa Selected Objects conforme necessário.

      • Se você não selecionar Incremental Data Migration, não grave novos dados na instância de origem durante a migração de dados para garantir a consistência dos dados.

      Method to Migrate Triggers in Source Database

      Selecione um método de migração de trigger. Ignore esta etapa se nenhum trigger estiver envolvido. Configure a method to synchronize or migrate triggers.

      Nota

      Este parâmetro está disponível apenas se você selecionar Migration Types e Incremental Data Migration para Schema Migration.

      Enable Migration Assessment

      Avalia se os schemas de origem e destino (comprimento do índice, stored procedures, tabelas dependentes) atendem aos requisitos. Selecione Yes ou No com base nas suas necessidades.

      Nota
      • Você pode configurar este parâmetro apenas se selecionar Schema Migration para Migration Types.

      • Se você selecionar Yes, a pré-verificação pode levar mais tempo. Você pode visualizar o Assessment Result durante a pré-verificação. O resultado da avaliação não afeta o resultado da pré-verificação.

      Processing Mode of Conflicting Tables

      • Precheck and Report Errors: Verifica se existem tabelas com os mesmos nomes no banco de dados de destino. Se não existirem tabelas com os mesmos nomes, a pré-verificação é aprovada. Se existirem tabelas com os mesmos nomes, um erro é relatado durante a pré-verificação e a tarefa de migração de dados não é iniciada.

        Nota

        Se uma tabela no banco de dados de destino tiver o mesmo nome, mas não puder ser facilmente excluída ou renomeada, você pode alterar o nome da tabela no banco de dados de destino. Para mais informações, consulte Object name mapping.

      • Ignore Errors and Proceed: Ignora a verificação de tabelas com os mesmos nomes.

        Aviso

        Selecionar Ignore Errors and Proceed pode causar inconsistência de dados e riscos ao negócio. Por exemplo:

        • Se os schemas das tabelas forem consistentes e um registro no banco de dados de destino tiver o mesmo valor de chave primária que um registro no banco de dados de origem:

          • Durante a migração completa, o DTS mantém o registro no banco de dados de destino. O registro do banco de dados de origem não é migrado.

          • Durante a migração incremental, o DTS não mantém o registro no banco de dados de destino. O registro do banco de dados de origem sobrescreve o registro no banco de dados de destino.

        • Se os schemas das tabelas forem inconsistentes, apenas algumas colunas de dados podem ser migradas, ou a migração pode falhar. Prossiga com cautela.

      Whether to migrate Event

      Escolha se deseja migrar eventos do banco de dados de origem. Se você selecionar Yes, etapas adicionais são necessárias. Synchronize or migrate events.

      Capitalization of Object Names in Destination Instance

      Você pode configurar a política de diferenciação de maiúsculas e minúsculas para os nomes dos objetos migrados, como bancos de dados, tabelas e colunas, na instância de destino. Por padrão, DTS default policy está selecionada. Você também pode escolher manter a diferenciação de maiúsculas e minúsculas consistente com a política padrão do banco de dados de origem ou destino. Para mais informações, consulte Case sensitivity of object names in the destination database.

      Source Objects

      Selecione um ou mais objetos na seção Source Objects. Clique no ícone Rightwards arrow e adicione os objetos à seção Selected Objects.

      Nota

      A granularidade para selecionar objetos de migração é banco de dados, tabela e coluna. Se você selecionar apenas tabelas ou colunas como objetos de migração, outros objetos como views, triggers e stored procedures não serão migrados para o banco de dados de destino.

      Selected Objects

      • Para alterar o nome de um único objeto de migração na instância de destino, clique com o botão direito no objeto na caixa Selected Objects. Para mais informações, consulte Map individual schema, table, and column names.

      • Para alterar os nomes de vários objetos de migração na instância de destino, clique em Selected Objects no canto superior direito da caixa Batch Edit. Para mais informações, consulte Map multiple schema, table, and column names.

      Nota
      • O mapeamento de nome de objeto pode causar falha na migração de objetos dependentes.

      • Para filtrar dados por uma condição WHERE, clique com o botão direito na tabela na seção Selected Objects e configure a condição. Filter data to be migrated.

      • Para selecionar operações SQL a serem migradas no nível do banco de dados ou tabela, clique com o botão direito no objeto na seção Selected Objects e escolha as operações na caixa de diálogo.

    2. Clique em Next: Advanced Settings para configurar parâmetros avançados.

      Parâmetro

      Descrição

      Dedicated Cluster for Task Scheduling

      Por padrão, o DTS agenda tarefas em um cluster compartilhado. Não é necessário selecionar um. Para obter tarefas mais estáveis, adquira um dedicated cluster para executar tarefas de migração do DTS.

      Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database.

      Se você usar Data Management (DMS) ou gh-ost para realizar alterações DDL online no banco de dados de origem, poderá escolher se deseja migrar os dados das tabelas temporárias geradas pelas alterações DDL online.

      Importante
      • Não há suporte para o uso de ferramentas como pt-online-schema-change para realizar alterações DDL online nas tarefas do DTS. Caso contrário, a tarefa do DTS falhará.

      • Os métodos de processamento para cada fase são os seguintes: As fases Schema Migration e Full Data Migration não permitem operações DDL que alterem a estrutura do banco de dados ou da tabela. Portanto, elas não são controladas pela política DDL online.

        • Schema Migration: Não controlada pela política DDL online. Tabelas temporárias relacionadas são criadas.

        • Full Data Migration: Não controlada pela política DDL online. A migração de tabelas temporárias não está incluída nos objetos de migração completa. Todas as tabelas cujos nomes correspondem à expressão regular (^_(.+)_(?:gho|new)$ ou ^_(.+)_(?:ghc|del|old)$) são filtradas.

        • Incremental Data Migration: Controlada pela política DDL online.

          • Yes: Migra alterações de dados de tabelas temporárias (por exemplo, _table_name_gho) geradas por operações DDL online.

          • No, Adapt to DMS Online DDL e No, Adapt to gh-ost: Filtra alterações de dados de tabelas temporárias (por exemplo, _table_name_gho) geradas por ferramentas como gh-ost com base em regras de expressão regular.

      • Yes: Migra os dados das tabelas temporárias geradas pelas alterações DDL online.

        Nota

        Se as alterações DDL online gerarem uma grande quantidade de dados em tabelas temporárias, isso pode causar latência na tarefa.

      • No, Adapt to DMS Online DDL: Não migra os dados das tabelas temporárias geradas pelas alterações DDL online. Migra apenas as instruções DDL originais executadas usando Data Management (DMS).

        Nota

        Esta opção causa o bloqueio das tabelas no banco de dados de destino.

      • No, Adapt to gh-ost: Não migra os dados das tabelas temporárias geradas pelas alterações DDL online. Suporta regras de filtragem personalizadas. O DTS filtra alterações de dados de tabelas temporárias (por exemplo, _table_name_gho) geradas por ferramentas como gh-ost com base em regras de expressão regular. Se necessário, modifique as expressões regulares padrão usadas para corresponder a tabelas shadow e useless:

        • Tabela shadow: ^_(.+)_(?:gho|new)$

        • Tabela useless: ^_(.+)_(?:ghc|del|old)$

        Nota

        Esta opção causa o bloqueio das tabelas no banco de dados de destino.

      Whether to Migrate Accounts

      Escolha se deseja migrar contas do banco de dados de origem. Se você selecionar Yes, selecione as contas a serem migradas e confirme suas permissões.

      Retry Time for Failed Connections

      Após o início da tarefa de migração, se a conexão com o banco de dados de origem ou destino falhar, o DTS reportará um erro e iniciará imediatamente as tentativas de reconexão. O tempo padrão de tentativa de reconexão é de 720 minutos. Você pode personalizar o tempo de nova tentativa para um valor de 10 a 1440 minutos. Recomenda-se definir a duração para mais de 30 minutos. Se o DTS reconectar aos bancos de dados de origem e destino dentro da duração especificada, a tarefa de migração será retomada automaticamente. Caso contrário, a tarefa falhará.

      Nota
      • Para várias instâncias DTS que compartilham a mesma origem ou destino, o tempo de nova tentativa de rede é determinado pela configuração da última tarefa criada.

      • Como há cobrança pela tarefa durante o período de tentativa de reconexão, personalize o tempo com base nas suas necessidades de negócios ou libere a instância DTS o mais rápido possível após a liberação das instâncias de banco de dados de origem e destino.

      Retry Time for Other Issues

      Após o início da tarefa de migração, se ocorrer um problema que não seja de conectividade, como uma exceção de execução DDL ou DML, no banco de dados de origem ou destino, o DTS reportará um erro e iniciará imediatamente a tentativa de repetição da operação. O tempo padrão de tentativa de reconexão é de 10 minutos. Você pode personalizar o tempo de nova tentativa para um valor de 1 a 1440 minutos. Recomenda-se definir a duração para mais de 10 minutos. Se as operações relacionadas forem bem-sucedidas dentro da duração de nova tentativa especificada, a tarefa de migração será retomada automaticamente. Caso contrário, a tarefa falhará.

      Importante

      O valor de Retry Time for Other Issues deve ser menor que o valor de Retry Time for Failed Connections.

      Enable Throttling for Full Data Migration

      Durante a migração completa, o DTS consome recursos de leitura e gravação nos bancos de dados de origem e destino, o que pode aumentar a carga do banco de dados. Se necessário, ative o throttling para a tarefa de migração completa. Defina Queries per second (QPS) to the source database, RPS of Full Data Migration e Data migration speed for full migration (MB/s) para reduzir a carga no banco de dados de destino.

      Nota
      • Este item de configuração está disponível apenas se você selecionar Full Data Migration para Migration Types.

      • Você também pode adjust the full migration speed após a instância de migração estar em execução.

      Enable Throttling for Incremental Data Migration

      Se necessário, defina limites de velocidade para a tarefa de migração incremental. Defina RPS of Incremental Data Migration e Data migration speed for incremental migration (MB/s) para reduzir a carga no banco de dados de destino.

      Nota
      • Este item de configuração está disponível apenas se você selecionar Incremental Data Migration para Migration Types.

      • Você também pode adjust the incremental migration speed após a instância de migração estar em execução.

      Environment Tag

      Tag de ambiente opcional para identificar a instância. Não é necessária para este exemplo.

      Whether to delete SQL operations on heartbeat tables of forward and reverse tasks

      Escolha se deseja gravar informações SQL de heartbeat no banco de dados de origem quando a instância DTS estiver em execução.

      • Yes: As informações SQL de heartbeat não são gravadas no banco de dados de origem. Isso pode fazer com que a instância DTS reporte um atraso.

      • No: Grava informações SQL de heartbeat no banco de dados de origem. Isso pode interferir em recursos como backup físico e clonagem do banco de dados de origem.

      Configure ETL

      Com base nas suas necessidades de negócios, escolha se deseja configurar o ETL feature para processar dados.

      Monitoring and Alerting

      Escolha se deseja definir alertas e receber notificações de alerta com base nas suas necessidades de negócios.

      • No: Não define alertas.

      • Yes: Configure alertas definindo um alert threshold e um alert notifications. Se uma migração falhar ou a latência exceder o limiar, o sistema envia uma notificação de alerta.

    3. Clique em Next: Data Validation para configurar uma tarefa de validação de dados.

      Para mais informações sobre o recurso de validação de dados, consulte Configure data validation.

  6. Agora, salve a tarefa e execute uma pré-verificação.

    • Se desejar, visualize os parâmetros de configuração desta instância ao chamar a operação de api, passe o ponteiro do mouse sobre o botão Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters na dica que aparece.

    • Se não for necessário visualizar ou se já tiver visualizado os parâmetros da api, clique em Next: Save Task Settings and Precheck na parte inferior da página.

    Nota
    • Antes do início da tarefa de migração, o DTS realiza uma pré-verificação. A tarefa só é iniciada após passar na pré-verificação.

    • Se a pré-verificação falhar, clique em View Details ao lado do item de verificação com falha, corrija o problema com base na mensagem e execute a pré-verificação novamente.

    • Se um aviso for reportado durante a pré-verificação:

      • Para itens de verificação que não podem ser ignorados, clique em View Details ao lado do item com falha, corrija o problema com base na mensagem e execute a pré-verificação novamente.

      • Para itens de verificação que podem ser ignorados, você pode clicar em Confirm Alert Details, Ignore, OK e Precheck Again para pular o item de alerta e executar a pré-verificação novamente. Se você optar por ignorar um aviso, isso pode causar problemas como inconsistência de dados e apresentar riscos ao seu negócio.

  7. Adquira a instância.

    1. Quando a Success Rate for 100%, clique em Next: Purchase Instance.

    2. Na página Purchase, selecione a especificação do link para a instância de migração de dados. Para mais informações, consulte a tabela a seguir.

      Categoria

      Parâmetro

      Descrição

      New Instance Class

      Resource Group Settings

      Selecione o grupo de recursos ao qual a instância pertence. O valor padrão é o grupo de recursos padrão. Para mais informações, consulte What is resource management?

      Instance Class

      O DTS fornece especificações de migração com diferentes níveis de desempenho. A especificação do link afeta a velocidade de migração. Selecione uma especificação com base no seu cenário de negócios. Para mais informações, consulte Data migration link specifications.

    3. Após concluir a configuração, leia e selecione Data Transmission Service (Pay-as-you-go) Service Terms.

    4. Clique em Buy and Start e, em seguida, clique em OK na caixa de diálogo OK.

      Visualize o progresso da tarefa na página Migration Tasks.

      Nota
      • Se a tarefa de migração não incluir migração incremental, ela será interrompida automaticamente após a conclusão da migração completa. Após a interrupção da tarefa, seu Status muda para Completed.

      • Se a tarefa de migração incluir migração incremental, ela não será interrompida automaticamente. A tarefa de migração incremental continua em execução. Enquanto a tarefa de migração incremental estiver em execução, o Status da tarefa será Running.

      • Para alternar cargas de trabalho, faça isso em horários de baixa demanda, quando a latência de migração for baixa ou zero. Switch workloads.

FAQ

P: Após o início da execução de uma instância, posso alterar Whether to delete SQL operations on heartbeat tables of forward and reverse tasks?

R: Não.