Todos os produtos
Search

Este produto

    Data Transmission Service:Migrar do ApsaraDB RDS for MySQL para o AnalyticDB for MySQL V3.0

    Central de documentação

    Data Transmission Service:Migrar do ApsaraDB RDS for MySQL para o AnalyticDB for MySQL V3.0

    Última atualização: Jul 17, 2026

    O Data Transmission Service (DTS) permite migrar dados de uma instância ApsaraDB RDS for MySQL para um cluster AnalyticDB for MySQL V3.0. Esse recurso ajuda você a criar rapidamente sistemas internos para business intelligence (BI), consultas interativas e relatórios em tempo real.

    Pré-requisitos

    • É necessário ter um cluster de destino AnalyticDB for MySQL V3.0. Para mais informações, consulte Criar um cluster.

    • A instância de destino AnalyticDB for MySQL deve ter mais espaço de armazenamento do que o utilizado pela instância de origem ApsaraDB RDS for MySQL.

    Limitações

    Nota

    • Durante a migração de schema, o DTS não migra chaves estrangeiras do banco de dados de origem para o banco de dados de destino.

    • Nas fases de migração total e incremental de dados, o DTS desativa temporariamente as verificações de restrições e as operações em cascata de chaves estrangeiras no nível da sessão. Caso ocorram atualizações ou exclusões em cascata no banco de dados de origem durante a execução da tarefa, pode haver inconsistência de dados.

    • O DTS não oferece suporte à migração de materialized views para a instância de destino AnalyticDB for MySQL durante a migração de schema. Para utilizar materialized views, crie-as manualmente na instância de destino após a conclusão da 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 precisa ter largura de banda de saída suficiente. Caso contrário, a velocidade de migração diminuirá.

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

    • Ao 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 esse limite for excedido, a tarefa falhará com um erro no momento do envio. Para corrigir, 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 origem MySQL autogerenciada for um cluster dual-master — onde cada instância atua simultaneamente como master e slave —, ative o parâmetro log_slave_updates. Isso garante que o DTS consiga ler todos os logs binários.

      • Para instâncias RDS for MySQL, mantenha os logs binários locais por pelo menos três dias (sete dias é o recomendado). Para bancos de dados MySQL autogerenciados, retenha os logs binários locais por no mínimo 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 logs binários inferiores aos exigidos pelo DTS não são cobertos pelo SLA do service.

        Nota

        Para definir o retention period dos logs binários locais em uma instância RDS for MySQL, consulte Excluir automaticamente logs locais.

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

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

        Nota

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

      • Não execute operações DDL que adicionem comentários — como ALTER TABLE table_name COMMENT='Table comment';. Do contrário, a tarefa de migração falhará.

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

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

      Nota

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

    • Se o banco de dados MySQL de origem for da versão 8.0.23 ou posterior e contiver colunas ocultas invisíveis, 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: Ao migrar dados de um banco de origem da família MySQL, o DTS depende do protocolo padrão MySQL e do formato Binlog. Comportamentos incompatíveis com o MySQL padrão não são suportados. Se o banco de dados de origem declarar compatibilidade com MySQL, mas apresentar comportamento diferente (por exemplo, quando o OceanBase é conectado como origem no modo MySQL, o timestamp do evento rotate final no Binlog é 0, diferentemente do MySQL), a tarefa de migração do DTS pode falhar.

    Outros limites

    • Índices de prefixo não são suportados. Se o banco de dados de origem contiver índices de prefixo, a migração pode falhar.

    • O DTS não oferece suporte à migração de objetos INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER ou FK.

    • Se o banco de dados de origem utilizar operações DDL online no modo de tabela temporária — incluindo cenários de mesclagem de múltiplas tabelas — ou adicionar índices baseados em funções a colunas de chave única, pode ocorrer perda de dados ou falha na tarefa no banco de dados de destino.

    • Se ocorrer um conflito de chave primária ou única 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:

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

        • Na 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 existente no destino.

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

    • O banco de dados de destino deve ter uma chave primária personalizada. Alternativamente, na etapa Configurations for Databases, Tables, and Columns, defina a Primary Key Column. Caso contrário, a migração pode falhar.

    • Devido aos limites intrínsecos do AnalyticDB for MySQL, se o uso de espaço em disco nos nós ultrapassar 80%, as tarefas do DTS apresentarão anomalias e atrasos. Estime antecipadamente o espaço necessário com base nos objetos a serem migrados e garanta que o cluster de destino tenha armazenamento suficiente.

    • Se o cluster de destino AnalyticDB for MySQL 3.0 estiver realizando backup enquanto a tarefa do DTS está em execução, a tarefa falhará.

    • Antes da migração, avalie o desempenho dos bancos de dados de origem e de destino. Execute a migração fora dos horários de pico. Caso contrário, a migração total consumirá recursos de leitura e gravação em ambos os bancos, aumentando a carga sobre eles.

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

    • Confirme se a precisão da migração do DTS para colunas FLOAT ou DOUBLE atende às necessidades do seu negócio. 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 dentro de sete dias. Antes de direcionar 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 evita que a recuperação automática sobrescreva os dados de destino com dados da origem.

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

    • Se a instância RDS for MySQL tiver o Always-Encrypted ativado, a migração total não é suportada.

      Nota

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

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

      Nota

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

    Casos especiais

    • Para origens MySQL autogerenciadas:

      • Um failover entre master e standby no banco de dados de origem causa falha na 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 um longo período, o relatório de latência torna-se impreciso. Se a latência parecer muito alta, execute uma operação DML na origem para atualizar o valor.

        Nota

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

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

      • Se a 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 — aponte sempre 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, instâncias RDS for MySQL que não registram logs de transações — como instâncias somente leitura do RDS for MySQL 5.6 — não são suportadas como origem.

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

    Faturamento

    Tipo de migração

    Taxa de configuração da instância

    Taxa de tráfego pela Internet

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

    Gratuito.

    Quando o parâmetro Access Method do banco de dados de destino estiver definido como Public IP Address, haverá cobrança de tráfego pela Internet. Para mais informações, consulte Visão geral do faturamento.

    Migração incremental de dados

    Pago. Para mais informações, consulte Visão geral do faturamento.

    Tipos de migração

    • Migração de schema

      O DTS migra os schemas dos objetos selecionados do banco de dados de origem para o banco de dados de destino.

      Nota

      Isso se aplica a migrações entre bancos de dados heterogêneos. Como os tipos de dados podem não ter correspondência perfeita durante a migração de schema, é essencial avaliar cuidadosamente o impacto no negócio. Para mais informações, consulte Mapeamento de tipos de dados para bancos de dados heterogêneos.

    • Migração total de dados

      O DTS migra todos os dados dos objetos selecionados no banco de dados de origem para o banco de dados de destino.

    • Migração incremental de dados

      Após a conclusão da migração total, o DTS migra as alterações incrementais de dados do banco de dados de origem para o destino. Esse processo permite uma migração suave, sem interrupção de service para suas aplicações autogerenciadas.

    Operações SQL suportadas

    Tipo de operação

    Instrução SQL

    DML

    INSERT, UPDATE e DELETE

    Nota

    Ao gravar dados no AnalyticDB for MySQL, o sistema converte automaticamente instruções UPDATE em REPLACE INTO. Se você atualizar uma chave primária, a instrução UPDATE será convertida em um DELETE seguido por um INSERT.

    DDL

    CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, ADD COLUMN, MODIFY COLUMN e DROP COLUMN

    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 renomeá-la 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 todo o banco de dados 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.
    Aviso

    Se o tipo de dados de um campo na tabela de origem for alterado durante a migração de dados, a tarefa será interrompida e reportará um erro. Para resolver o problema, siga estas etapas:

    1. Uma tarefa de migração para o banco de dados de destino AnalyticDB for MySQL falha se o tipo de dados de um campo na tabela de origem (por exemplo, customer) for alterado.

    2. No AnalyticDB for MySQL V3.0, crie uma nova tabela, por exemplo customer_new, com o schema atualizado da tabela de origem.

    3. Use o comando INSERT INTO SELECT para copiar os dados da tabela original customer para customer_new.

    4. Renomeie ou exclua a tabela original customer e, em seguida, renomeie customer_new para customer.

    5. No console do DTS, reinicie a tarefa de migração de dados.

    Permissões da conta do banco de dados

    Banco de dados

    Migração de schema

    Migração total

    Migração incremental

    ApsaraDB RDS for MySQL

    Permissão SELECT

    Permissão SELECT

    Permissões REPLICATION SLAVE, REPLICATION CLIENT e SELECT sobre os objetos a serem migrados. O DTS concede essas permissões automaticamente.

    AnalyticDB for MySQL 3.0

    Permissões de leitura e gravação

    Para criar e autorizar uma conta de banco de dados, consulte os seguintes tópicos:

    Procedimento

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

      Pelo console do DTS

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

      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.

      Pelo console do DMS

      Nota

      As operações reais podem variar conforme o modo e o layout do console do DMS. Para mais informações, consulte Console no modo simples e Personalizar o layout e o estilo do console do DMS.

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

      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 para acessar a página de configuração da tarefa.

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

      Aviso

      Após selecionar as instâncias de origem e de destino, recomendamos que leia atentamente as limitações exibidas no topo da página. Caso contrário, a tarefa pode falhar ou ocorrer inconsistência de dados.

      Seção

      Parâmetro

      Descrição

      N/A

      Task Name

      O DTS gera automaticamente um nome para a tarefa. Recomendamos especificar um nome descritivo para facilitar a identificação. O nome não precisa ser único.

      Source Database

      Select Existing Connection

      • Para usar uma instância de banco de dados que já foi adicionada ao sistema (criada ou salva), selecione a instância desejada na lista suspensa. As informações do banco de dados abaixo serão configuradas automaticamente.

        Nota

        No console do DMS, este parâmetro chama-se Select a DMS database instance..

      • Se você não registrou a instância de banco de dados no sistema ou não precisa usar uma instância registrada, configure manualmente 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 de origem ApsaraDB RDS for MySQL.

      Cross-account

      Este exemplo mostra uma migração dentro da mesma conta Alibaba Cloud. Selecione No.

      RDS Instance ID

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

      Database Account

      Insira a conta do banco de dados para a instância de origem ApsaraDB RDS for MySQL. Para informações sobre as permissões necessárias, consulte Permissões necessárias para contas de banco de dados.

      Database Password

      Insira a senha da conta do banco de dados.

      Encryption

      Selecione Non-encrypted ou SSL-encrypted conforme os 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 antecipadamente. Para mais informações, consulte Ativar rapidamente a criptografia SSL usando um certificado cloud.

      Destination Database

      Select Existing Connection

      • Para usar uma instância de banco de dados que já foi adicionada ao sistema (criada ou salva), selecione a instância desejada na lista suspensa. As informações do banco de dados abaixo serão configuradas automaticamente.

        Nota

        No console do DMS, este parâmetro chama-se Select a DMS database instance..

      • Se você não registrou a instância de banco de dados no sistema ou não precisa usar uma instância registrada, configure manualmente as informações do banco de dados abaixo.

      Database Type

      Selecione AnalyticDB for MySQL 3.0.

      Access Method

      Selecione Alibaba Cloud Instance.

      Instance Region

      Selecione a região do cluster de destino AnalyticDB for MySQL 3.0.

      Instance ID

      Selecione o ID da instância do cluster de destino AnalyticDB for MySQL 3.0.

      Database Account

      Insira a conta do banco de dados para o cluster de destino AnalyticDB for MySQL 3.0. Para informações sobre as permissões necessárias, consulte Permissões necessárias para contas de banco de dados.

      Database Password

      Insira a senha da conta do banco de dados.

    4. Após concluir a configuração, clique em Test Connectivity and Proceed na parte inferior da página.

      Nota

      • Certifique-se de que o segmento de endereços IP do service DTS foi adicionado automática ou manualmente às configurações de segurança dos bancos de dados de origem e de destino para permitir o acesso dos servidores DTS. Para mais informações, consulte Adicionar endereços IP de servidores DTS a uma lista de permissões.

      • Se o banco de dados de origem ou de destino for autogerenciado (o Access Method não é Alibaba Cloud Instance), você também deve clicar em Test Connectivity na caixa de diálogo CIDR Blocks of DTS Servers que aparece.

    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 migração total de dados apenas, selecione Schema Migration e Full Data Migration.

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

        Nota

        • Se você selecionar Full Data Migration, o schema e os dados das tabelas criadas com a instrução CREATE TABLE poderão ser migrados para o banco de dados de destino.

        • 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.

        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 nomes iguais, a pré-verificação é aprovada. Se existirem, 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ê poderá alterar o nome da tabela no banco de dados de destino. Para mais informações, consulte Mapeamento de nomes de objetos.

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

          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:

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

            • Na 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 existente no destino.

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

        DDL and DML Operations to Be Synchronized

        Selecione as operações SQL no nível da instância para a migração incremental de dados. Para obter uma lista de operações suportadas, consulte Operações SQL suportadas para migração incremental.

        Nota

        Para selecionar operações SQL no nível do banco de dados ou da tabela, clique com o botão direito em um objeto no painel Selected Objects e selecione as operações SQL desejadas na caixa de diálogo que aparece.

        Merge Tables

        • Se você selecionar Yes, o DTS adicionará a coluna __dts_data_source a cada tabela para registrar as fontes de dados. Para mais informações, consulte Ativar mesclagem de múltiplas tabelas.

        • Se você selecionar No, esta é a opção padrão.

        Nota

        O recurso de mesclagem de tabelas é configurado no nível da tarefa, não no nível da tabela. Para mesclar algumas tabelas, mas não outras, você deve criar duas tarefas separadas de migração de dados.

        Aviso

        Não execute operações DDL para alterar o schema do banco de dados ou das tabelas de origem. Caso contrário, pode ocorrer inconsistência de dados ou falha na tarefa.

        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, a DTS default policy está selecionada. Você também pode optar por manter a sensibilidade a maiúsculas e minúsculas consistente com a política padrão da origem ou do destino. Para mais informações, consulte Sensibilidade a maiúsculas e minúsculas de nomes de objetos no banco de dados de destino.

        Source Objects

        Na caixa Source Objects, clique nos objetos a serem migrados e, em seguida, clique em Right arrow para movê-los para a caixa Selected Objects.

        Nota

        • Você pode selecionar objetos de migração no nível do banco de dados, da tabela ou da coluna. Se selecionar tabelas 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.

        • Se você selecionar um banco de dados inteiro como objeto de migração, aplicam-se as seguintes regras padrão:

          • Se uma tabela no banco de dados de origem tiver uma chave primária (coluna única ou composta), a(s) coluna(s) da chave primária serão usadas como chave de distribuição.

          • Se uma tabela no banco de dados de origem não tiver uma chave primária, uma coluna de chave primária com incremento automático será gerada automaticamente. Isso pode causar inconsistência de dados entre os bancos de dados de origem e de destino.

        Selected Objects
        Nota

        • Se você usar o recurso de mapeamento de nomes de objetos, a migração de outros objetos que dependem do objeto renomeado pode falhar.

        • Para filtrar dados usando uma cláusula WHERE, clique com o botão direito em uma tabela no painel Selected Objects e especifique a condição de filtro na caixa de diálogo que aparece. Para obter instruções, consulte Definir condições de filtro.

        • Para selecionar operações SQL no nível do banco de dados ou da tabela, clique com o botão direito em um objeto de migração no painel Selected Objects e selecione as operações SQL desejadas na caixa de diálogo que aparece.

        • Você também pode clicar com o botão direito em uma tabela no painel Selected Objects para adicionar colunas. Para mais informações, consulte Adicionar colunas adicionais.

      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. Se desejar tarefas mais estáveis, você pode adquirir um cluster dedicado 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 o 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

        • As tarefas do DTS não suportam o uso de ferramentas como pt-online-schema-change para realizar alterações DDL online. Caso contrário, a tarefa do DTS falhará.

        • Os métodos de processamento para cada fase são os seguintes: As fases de 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 de DDL online.

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

          • Full Data Migration: Não controlada pela política de DDL online. A migração de tabelas temporárias não está incluída nos objetos de migração total. 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 de 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 o Data Management (DMS).

          Nota

          Esta opção faz com que as tabelas no banco de dados de destino sejam bloqueadas.

        • 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. Você pode modificar as expressões regulares padrão usadas para corresponder a tabelas shadow e inúteis conforme necessário:

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

          • Tabela inútil: ^_(.+)_(?:ghc|del|old)$

          Nota

          Esta opção faz com que as tabelas no banco de dados de destino sejam bloqueadas.

        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 de destino falhar, o DTS relatará um erro e começará imediatamente a tentar reconectar. A duração padrão de nova tentativa é de 720 minutos. Você pode personalizar o tempo de nova tentativa para um valor entre 10 e 1440 minutos. Recomendamos definir a duração para mais de 30 minutos. Se o DTS se reconectar aos bancos de dados de origem e de 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 do 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 nova tentativa de conexão, recomendamos personalizar o tempo de nova tentativa com base nas necessidades do seu negócio ou liberar a instância do DTS o mais rápido possível após a liberação das instâncias de banco de dados de origem e de destino.

        Retry Time for Other Issues

        Após o início da tarefa de migração, se ocorrer um problema não relacionado à conectividade, como uma exceção de execução DDL ou DML, no banco de dados de origem ou de destino, o DTS relatará um erro e começará imediatamente a tentar repetir a operação. A duração padrão de nova tentativa é de 10 minutos. Você pode personalizar o tempo de nova tentativa para um valor entre 1 e 1440 minutos. Recomendamos 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 total, o DTS consome recursos de leitura e gravação nos bancos de dados de origem e de destino, o que pode aumentar a carga sobre eles. Se necessário, você pode ativar o limitador de taxa para a tarefa de migração total. É possível definir 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 em Migration Types.

        • Você também pode ajustar a velocidade da migração total depois que a instância de migração estiver em execução.

        Enable Throttling for Incremental Data Migration

        Se necessário, você também pode optar por definir limites de velocidade para a tarefa de migração incremental. É possível definir 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 em Migration Types.

        • Você também pode ajustar a velocidade da migração incremental depois que a instância de migração estiver em execução.

        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 enquanto a instância do DTS está 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 do DTS relate 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.

        Environment Tag

        Você pode selecionar uma tag de ambiente para identificar a instância. Nenhuma seleção é necessária neste exemplo.

        Configure ETL

        Escolha se deseja ativar o recurso de extração, transformação e carregamento (ETL). Para mais informações, consulte O que é ETL? Valores válidos:

        Monitoring and Alerting

        Selecione se deseja definir alertas e receber notificações de alerta com base nas necessidades do seu negócio.

        • No: Não define alerta.

        • Yes: Configure alertas definindo um limiar de alerta e um notificações de alerta. Se uma migração falhar ou a latência exceder o limiar, o sistema enviará 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 Configurar validação de dados.

      4. Opcional: Após concluir as configurações anteriores, clique em Next: Configure Database and Table Fields para definir o Type, a Primary Key Column, a Distribution Key e as informações da chave de partição (Partition Key, Partitioning Rules e Partition Lifecycle) para as tabelas a serem migradas no banco de dados de destino.

        Nota

        • Esta etapa está disponível apenas se você selecionar a opção Schema Migration em Migration Types ao configurar os objetos da tarefa. Você pode selecionar All em Definition Status para fazer modificações.

        • Você pode selecionar várias colunas para Primary Key Column para formar uma chave primária composta. Você também deve selecionar uma ou mais colunas da Primary Key Column para usar como Distribution Key e Partition Key. Para mais informações, consulte CREATE TABLE.

    6. Salve a tarefa e execute uma pré-verificação.

      • Para visualizar os parâmetros de configuração desta instância ao chamar a operação da API, passe o ponteiro sobre o botão Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters no balão que aparece.

      • Se você não precisar visualizar ou já tiver terminado de visualizar 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ó começa após ser aprovada 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 conforme a orientação e execute a pré-verificação novamente.

      • Se um aviso for relatado 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 conforme a orientação 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 representar riscos ao seu negócio.

    7. Adquira a instância.

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

      2. Na página Purchase, selecione a especificação de 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 é default resource group. Para mais informações, consulte O que é 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 da migração. Você pode selecionar uma especificação com base no cenário do seu negócio. Para mais informações, consulte Especificações de link de migração de dados.

      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. Na caixa de diálogo OK que aparece, clique em OK.

        Você pode visualizar o progresso da tarefa de migração na página de lista Data 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 total. 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.

    Perguntas frequentes

    • O que devo fazer se o erro only 500 dimension table allowed, current dimensionTableCount: 500 for relatado durante a sincronização ou migração de schema?

      • Causa: No AnalyticDB for MySQL, o número total de tabelas inclui tabelas em uso e tabelas na lixeira. Se o total exceder o limite, o erro será relatado. Para mais informações, consulte Limites.

      • Solução:

        1. Na tarefa do DTS, verifique se o número de tabelas sendo sincronizadas ou migradas excede o máximo indicado na mensagem de erro.

        2. Se o número de tabelas não exceder o máximo, execute as seguintes instruções para verificar se há tabelas excluídas na lixeira. Para mais informações, consulte Lixeira de tabelas.

          -- Check tables currently used by the instance
SELECT COUNT(*) FROM INFORMATION_SCHEMA.tables;
-- Check tables in the recycle bin
SELECT COUNT(*) FROM INFORMATION_SCHEMA.KEPLER_META_RECYCLE_BIN;

        3. Se a lixeira contiver tabelas excluídas, execute as seguintes instruções para limpá-las.

          Importante

          Depois que as tabelas na lixeira forem limpas, elas não poderão ser recuperadas. Certifique-se de que essas tabelas não são mais necessárias.

          -- Delete all tables in the recycle bin.
PURGE RECYCLE_BIN ALL;
-- Delete a specific table in the recycle bin.
PURGE RECYCLE_BIN TABLE <table_name_in_ADB_RECYCLE_BIN>;