Todos os produtos
Search

Este produto

    ApsaraDB for MongoDB:Migrar um cluster fragmentado do MongoDB auto-gerenciado com o DTS

    Central de documentação

    ApsaraDB for MongoDB:Migrar um cluster fragmentado do MongoDB auto-gerenciado com o DTS

    Última atualização: Aug 26, 2026

    Migre um cluster fragmentado do MongoDB auto-gerenciado para o ApsaraDB for MongoDB, processando um shard por vez, utilizando o Data Transmission Service (DTS). A migração incremental do DTS mantém sua aplicação em execução durante o processo.

    Para outras opções, consulte Overview of MongoDB data migration and synchronization solutions.

    Pré-requisitos

    • Verifique se as versões do MongoDB de origem e de destino são suportadas. Consulte as combinações de versões compatíveis em Migration solutions.

      ta-tag="xref" id="xref_78n_86r_96y" href="t17092.dita#concept_26618_zh">Soluções de migração.

    • Garanta que cada shard na instância do cluster fragmentado de destino possua espaço de armazenamento suficiente.

      Nota

      Exemplo: Se o maior shard no banco de dados de origem utilizar 500 GB, cada shard na instância de destino deve ter mais de 500 GB de armazenamento.

      seu banco de dados de origem utiliza 500 GB, cada shard na instância de destino deve ter mais de 500 GB de armazenamento.

    Como funciona

    O DTS migra um cluster fragmentado processando um shard por vez. Crie uma tarefa de migração separada para cada shard.

    Nota

    A distribuição dos dados depende da chave de fragmentação configurada. Configure data sharding to maximize shard performance.

    Migration architecture

    Observações de uso

    • A migração completa de dados aumenta a carga nos bancos de dados de origem e de destino. Execute a migração fora do horário de pico para evitar interrupções no service.

      evitar interrupções no service.

    • Ao migrar entre versões ou mecanismos de armazenamento diferentes, verifique primeiro a compatibilidade em Versions and storage engines.

      a#concept_qg2_xcr_52b">Versões e mecanismos de armazenamento primeiro.

    • Como o DTS grava dados simultaneamente, o banco de dados de destino pode usar de 5% a 10% mais armazenamento do que a origem.

      banco de dados pode usar de 5% a 10% mais armazenamento do que a origem.

    • Certifique-se de que o destino não contenha documentos com a mesma chave primária (_id por padrão) que a origem. Caso existam conflitos e a exclusão não afete seus negócios, exclua os documentos conflitantes do destino antes da migração.

      existirem conflitos e a exclusão não afetar seus negócios, exclua os documentos conflitantes do destino antes da migração.

    • Os bancos de dados admin e local não podem ser usados como origem ou destino.

      não podem ser usados como origem ou destino.

    • O cluster fragmentado do MongoDB de origem pode ter no máximo 10 nós mongos.

      ter no máximo 10 nós mongos.

    Faturamento

    Tipo de migração

    Taxa de configuração da tarefa

    Taxa de tráfego de Internet

    Migração completa de dados

    Gratuito.

    Dados migrados para fora da Alibaba Cloud pela internet pública incorrem em cobranças. DTS Pricing.

    Migração incremental de dados

    Cobrado. .DTS Pricing

    Tipos de migração

    • Migração completa de dados: Copia todos os dados existentes dos objetos de origem selecionados para o destino.

      Nota

      Inclui bancos de dados, coleções e índices.

      n1y_f19">

      Inclui bancos de dados, coleções e índices.

    • Migração incremental de dados: Após a conclusão da migração completa, o DTS sincroniza continuamente as alterações de dados da origem para o destino.

      Nota

      • O DTS sincroniza operações de criação e exclusão para bancos de dados, coleções e índices.

      • O DTS sincroniza operações de criação, exclusão e atualização para documentos.

      e operações de exclusão para bancos de dados, coleções e índices. ns para bancos de dados, coleções e índices.

    • O DTS sincroniza operações de criação, exclusão e atualização para documentos.

      te e operações de atualização para documentos.

    Permissões de conta de banco de dados

    Banco de dados

    Migração completa de dados

    Migração incremental de dados

    Banco de dados MongoDB auto-gerenciado

    Permissão read nos bancos de dados a serem migrados.

    Permissão read nos bancos de dados a serem migrados, além dos bancos de dados admin e local.

    Instância do ApsaraDB for MongoDB

    Permissão readWrite no banco de dados de destino.

    Permissão readWrite no banco de dados de destino.

    Para criar contas de banco de dados e conceder permissões:

    Antes de começar

    1. Obrigatório: Desative o balancer durante a migração para evitar inconsistências de dados. Manage the balancer of a MongoDB instance.

      Aviso

      Se o balancer não for desativado, as migrações de chunks podem afetar a consistência dos dados lidos pelo DTS.

      "c43899c026iua">Se o balancer não for desativado, as migrações de chunks podem afetar a consistência dos dados lidos pelo DTS.

    2. Remova documentos órfãos criados por falhas na migração de chunks do banco de dados de origem.

      Nota

      Documentos órfãos podem degradar o desempenho da migração e causar conflitos de _id que levam a erros.

      1. Baixe o script cleanupOrphaned.js.

        wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

      2. No script cleanupOrphaned.js, substitua test pelo nome do banco de dados a ser limpo.

        Nota

        Se você tiver vários bancos de dados, repita esta etapa e step c.

        function cleanupOrphaned(coll) {
  var nextKey = { };
  var result;
  while ( nextKey != null ) {
    result = db.adminCommand( { cleanupOrphaned: coll, startingFromKey: nextKey } );
    if (result.ok != 1)
      print("Unable to complete at this time: failure or timeout.")
    printjson(result);
    nextKey = result.stoppedAtKey;
  }
}
var dbName = 'test'
db = db.getSiblingDB(dbName)
db.getCollectionNames().forEach(function(collName) {
        cleanupOrphaned(dbName + "." + collName);
});

      3. Execute este comando em cada shard para remover documentos órfãos de todas as coleções no banco de dados.

        Nota

        Execute em todos os shards.

        mongo --host <Shardhost> --port <Primaryport>  --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js
        Nota

        • <Shardhost>: O endereço IP do shard.

        • <Primaryport>: A porta de service do nó primário no shard.

        • <database>: O banco de dados de autenticação da conta.

        • <username>: A conta do banco de dados.

        • <password>: A senha da conta.

        Exemplo com três shards:

        mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
        mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
        mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

      d826nfg"><password>: A senha da conta.

    3. Exemplo com três shards:

      5. mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
      mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
      mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

    5. g="codeblock" id="codeblock_6ze_gis_zmv" outputclass="language-plaintext" code-type="xCode">mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

      6. mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

    Crie bancos de dados e coleções que precisam de fragmentação na instância de destino e configure o sharding de dados. Configure data sharding to maximize shard performance.

    Nota

    Configurar o sharding antes da migração evita que todos os dados sejam gravados em um único shard, excedendo sua capacidade de armazenamento.

    ote" id="note_keh_seo_9uz">

    Configurar o sharding antes da migração evita que todos os dados sejam gravados em um único shard, excedendo sua capacidade de armazenamento.

    Limites

    Limites do banco de dados de origem

    • O servidor deve ter largura de banda de saída suficiente. Largura de banda insuficiente desacelera a migração

    • As coleções a serem migradas devem ter restrições PRIMARY KEY ou UNIQUE, com todos os campos únicos. Caso contrário, registros duplicados podem aparecer no destino

    • O DTS utiliza recursos de leitura e gravação nos bancos de dados de origem e de destino durante a migração completa de dados, o que aumenta a carga do servidor. Execute migrações fora do horário de pico

    • Se os bancos de dados de origem e de destino usarem versões diferentes do MongoDB ou mecanismos de armazenamento distintos, verifique a compatibilidade primeiro. Consulte MongoDB versions and storage engines

    • Para migração incremental de dados, ative o oplog no banco de dados de origem e retenha o oplog por pelo menos 7 dias. Se o oplog não estiver ativado, mensagens de erro serão retornadas durante a pré-verificação e a tarefa de migração de dados não poderá ser iniciada. Se o DTS não conseguir obter o oplog, a tarefa falhará e poderá ocorrer inconsistência ou perda de dados. Esses requisitos de retenção estão fora do acordo de nível de service (SLA) do DTS

    • Se você selecionar coleções como objetos de migração e planejar editá-las no destino (como renomear), uma única tarefa suporta até 1.000 coleções. Para mais de 1.000 coleções, configure várias tarefas ou migre o banco de dados inteiro

    • Não use o banco de dados admin ou local como origem ou destino

    • O banco de dados MongoDB auto-gerenciado de origem não pode ter mais de 10 nós mongos

    • Não migre coleções com índices time to live (TTL). Índices TTL podem causar inconsistência de dados entre a origem e o destino após a migração

    • Certifique-se de que não existam documentos órfãos no banco de dados de origem ou na instância do cluster fragmentado de destino. Documentos órfãos podem causar inconsistência de dados ou falha na tarefa. Consulte the MongoDB documentation e How do I delete orphaned documents of a MongoDB database deployed in the sharded cluster architecture?

    Durante a migração, não execute os seguintes comandos no banco de dados de origem — eles alteram a distribuição de dados e causam inconsistência:

    • shardCollection, reshardCollection, unshardCollection, moveCollection, movePrimary

    Durante a migração de esquema e a migração completa de dados:

    • Não realize alterações de esquema em bancos de dados ou coleções, incluindo atualização de tipos de array. Alterações de esquema causam falha na tarefa ou inconsistência de dados

    • Não grave dados no banco de dados de origem se executar apenas a migração completa de dados (sem incremental). Para garantir a consistência dos dados, selecione migração de esquema, migração completa de dados e migração incremental de dados juntas

    Se o balancer do banco de dados de origem estiver ativo durante a migração, a migração de chunks pode introduzir latência.

    Outros limites

    • Se você adquirir uma instância do DTS antes de configurar uma tarefa, especifique o número de shards no momento da compra

    • O DTS não consegue se conectar a um banco de dados MongoDB através de uma string de conexão SRV

    • Adicione chaves de fragmentação a todos os dados no banco de dados de origem antes de iniciar a migração. Durante a migração, as operações INSERT devem incluir chaves de fragmentação, e as operações UPDATE não podem modificar chaves de fragmentação

    • Desative o balancer para o banco de dados MongoDB de origem durante a migração completa de dados. Mantenha-o desativado até que cada subtarefa atinja a fase de migração incremental de dados. Reativá-lo prematuramente causa inconsistência de dados. Consulte Manage the ApsaraDB for MongoDB balancer

    • Certifique-se de que o banco de dados de destino não contenha documentos com a mesma chave primária (_id) que a origem. Se existirem duplicatas, exclua os documentos correspondentes no destino antes de iniciar a migração

    • Informações de transação não são retidas. Transações migradas são convertidas em registros individuais

    • Se ocorrer um conflito de chave primária ou chave única quando o DTS gravar no destino, o DTS ignora a gravação conflitante e retém os dados existentes

    • Não dimensione uma instância de cluster fragmentado do ApsaraDB for MongoDB enquanto uma tarefa de migração estiver em execução. O dimensionamento causa falha na tarefa

    • Consulte resultados de contagem no banco de dados ApsaraDB for MongoDB de destino usando db.$table_name.aggregate([{ $count:"myCount"}])

    • Como o DTS grava dados simultaneamente, o espaço de armazenamento usado no destino é 5–10% maior do que na origem

    • Se uma coleção de destino tiver um índice único ou o atributo capped definido como true, a coleção suporta apenas gravações single-threaded e não suporta replay simultâneo durante a migração incremental. Isso pode aumentar a latência da migração

    • A migração completa de dados usa recursos de leitura e gravação em ambos os bancos de dados, aumentando a carga do servidor. Execute migrações fora do horário de pico

    • Operações INSERT simultâneas durante a migração completa de dados causam fragmentação de tabela. Após a migração completa de dados, o tablespace no destino é maior do que na origem

    • O DTS tenta retomar tarefas de migração com falha por até 7 dias. Antes de alternar cargas de trabalho para a instância de destino, pare ou libere quaisquer tarefas com falha, ou revogue as permissões de gravação do DTS no destino. Caso contrário, os dados de origem sobrescreverão os dados de destino quando uma tarefa com falha for retomada

    • Se uma tarefa do DTS falhar, o suporte técnico do DTS tentará restaurá-la dentro de 8 horas. Durante a restauração, a tarefa pode reiniciar e parâmetros da tarefa podem ser modificados

      Apenas parâmetros da tarefa podem ser modificados — parâmetros do banco de dados não são alterados. Parâmetros que podem ser modificados estão listados na seção Modify instance parameters .

    • Se o destino for uma instância de conjunto de réplicas:

    • Se o destino for uma instância de cluster fragmentado, certifique-se de que o comportamento da sua aplicação atenda aos requisitos de cluster fragmentado do ApsaraDB for MongoDB

    Migrar dados

    Antes de começar

    Conclua as etapas a seguir antes de criar a tarefa do DTS.

    Etapa 1: Desativar o balancer do banco de dados de origem

    Desative o balancer no banco de dados MongoDB auto-gerenciado para evitar que a migração de chunks afete a consistência dos dados durante a tarefa do DTS.

    Aviso

    Se o balancer estiver ativo durante a migração, a migração de chunks fará com que o DTS leia dados inconsistentes.

    Para instruções, consulte Manage the ApsaraDB for MongoDB balancer.

    Etapa 2: Excluir documentos órfãos do banco de dados de origem

    Documentos órfãos deixados por falhas na migração de chunks comprometem o desempenho da migração, podem criar valores _id duplicados e podem causar a migração de dados indesejados.

    1. Baixe o arquivo cleanupOrphaned.js:

      wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

    2. No arquivo cleanupOrphaned.js, substitua test pelo nome do banco de dados do qual deseja excluir documentos órfãos.

      Para excluir documentos órfãos de vários bancos de dados, repita esta etapa e a próxima etapa para cada banco de dados.

      Replace the database name in cleanupOrphaned.js

    3. Execute o seguinte comando em cada shard para excluir documentos órfãos de todas as coleções no banco de dados especificado:

      Execute este comando em todos os shards.

      Marcador

      Descrição

      <Shardhost>

      Endereço IP do shard

      <Primaryport>

      Porta de service do nó primário no shard

      <database>

      Nome do banco de dados ao qual a conta pertence

      <username>

      Conta usada para fazer login no banco de dados MongoDB auto-gerenciado

      <password>

      Senha usada para fazer login no banco de dados MongoDB auto-gerenciado

      		 
      mongo --host <Shardhost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js

      Exemplo: Para um banco de dados de origem com três shards:

      mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

    Etapa 3: Configurar sharding na instância de destino (apenas cluster fragmentado)

    Se o destino for uma instância de cluster fragmentado, crie os bancos de dados e coleções a serem fragmentados e configure o sharding de dados antes de iniciar a migração. Isso distribui os dados migrados uniformemente entre os shards e evita que um único shard fique sobrecarregado.

    Consulte Configure sharding to maximize the performance of shards.

    Etapa 1: Abrir a página Data Migration

    Use um dos métodos a seguir para abrir a página Data Migration e selecione a região onde reside a instância de migração.

    Console do DTS

    1. Faça login no console do DTS.

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

    3. No canto superior esquerdo, selecione a região onde reside a instância de migração de dados.

    Console do DMS

    As etapas exatas podem variar dependendo do modo e layout do console do DMS. Consulte Simple mode e Customize the layout and style of the DMS console .

    1. Faça login no console do DMS.

    2. Na barra de navegação superior, acesse Data + AI > DTS (DTS) > Data Migration.

    3. Na lista suspensa à direita de Data Migration Tasks, selecione a região onde reside a instância de migração.

    Etapa 2: Criar uma tarefa

    Clique em Create Task para abrir a página de configuração da tarefa.

    Etapa 3: Configurar bancos de dados de origem e de destino

    Aviso

    Após configurar os bancos de dados de origem e de destino, leia os Limites exibidos no topo da página. Pular esta etapa pode causar falha na tarefa ou resultar em inconsistência de dados.

    Configure os seguintes parâmetros:

    Geral

    Parâmetro

    Descrição

    Task Name

    O DTS gera automaticamente um nome para a tarefa. Especifique um nome descritivo para facilitar a identificação da tarefa. Não é necessário um nome exclusivo.

    Banco de dados de origem

    Parâmetro

    Descrição

    Select Existing Connection

    Se a instância estiver registrada no DTS, selecione-a na lista suspensa — o DTS preencherá os parâmetros restantes automaticamente. Caso contrário, configure os parâmetros abaixo. No console do DMS, selecione na lista Select a DMS database instance.

    Database Type

    Selecione MongoDB.

    Access Method

    Selecione o método de conexão. Este exemplo usa Public IP Address. Para outros métodos, configure o ambiente de rede primeiro. Consulte Preparation overview.

    Instance Region

    A região onde reside o banco de dados de origem. Se a região não estiver listada, selecione a geograficamente mais próxima.

    Architecture

    Selecione Sharded Cluster. Esta opção aparece apenas para métodos de acesso Express Connect, VPN Gateway, Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN).

    Migration Method

    Selecione o método para migrar dados incrementais: Oplog (recomendado) ou ChangeStream. Oplog está disponível quando o oplog está ativado na origem (ativado por padrão tanto em bancos de dados auto-gerenciados quanto em instâncias do ApsaraDB for MongoDB) e fornece migração incremental de baixa latência. ChangeStream está disponível quando change streams estão ativados. Consulte Change Streams. Se a origem for um cluster Amazon DocumentDB inelástico, selecione apenas ChangeStream. Se Architecture estiver definido como Sharded Cluster, os parâmetros Shard account e Shard password não são necessários.

    Endpoint Type

    Selecione Standalone ou Multi-node com base na sua configuração. Este parâmetro aparece apenas para métodos de acesso Express Connect, VPN Gateway, Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN).

    Mongos Domain Name or IP Address

    O endpoint ou endereço IP de qualquer nó mongos. Aparece apenas quando Endpoint Type é Standalone. Defina Domain Name or IP para o endereço de qualquer nó mongos e Port Number para sua porta.

    Port Number

    A porta de service do nó mongos. Aparece apenas quando Endpoint Type é Standalone. A porta deve estar acessível pela Internet.

    Mongos endpoint

    O endpoint do banco de dados de origem no formato <IP>:<Port>. Aparece apenas quando Endpoint Type é Multi-node. Separe múltiplos endpoints com quebras de linha. Use um nome de domínio publicamente acessível sempre que possível.

    Authentication Database

    O banco de dados de autenticação para a origem. Padrão: admin.

    Database Account

    A conta para acessar nós mongos. Se Access Method for Self-managed Database on ECS ou Database Gateway, insira a conta de acesso ao shard.

    Database Password

    A senha da conta do banco de dados.

    Access to Multiple Shard Nodes

    As informações de acesso para nós de shard. Disponível apenas quando a arquitetura de origem é Sharded Cluster, Migration Method é Oplog, e Endpoint Type é Multi-node. Clique em Add, insira o endpoint de cada nó de shard no formato <IP>:<Port> (um por linha) e repita para todos os shards.

    Shard access information (IP:Port)

    O endereço IP e porta de cada shard, no formato IP:Port. Aparece apenas quando Endpoint Type é Standalone. Separe múltiplos shards com vírgulas.

    Shard account

    A conta para acessar shards no banco de dados de origem.

    Shard password

    A senha da conta do shard.

    Encryption

    O método de criptografia da conexão: Non-encrypted, SSL-encrypted ou Mongo Atlas SSL. As opções disponíveis dependem das configurações de Access Method e Architecture. Se Architecture for Sharded Cluster e Migration Method for Oplog, SSL-encrypted estará indisponível para o ApsaraDB for MongoDB. Se a origem usar arquitetura Replica Set, Access Method não for Alibaba Cloud Instance, e Encryption for SSL-encrypted, carregue um certificado CA para verificar a conexão.

    Banco de dados de destino

    Parâmetro

    Descrição

    Select Existing Connection

    Se a instância estiver registrada no DTS, selecione-a na lista suspensa. Caso contrário, configure os parâmetros abaixo.

    Database Type

    Selecione MongoDB.

    Access Method

    Selecione Alibaba Cloud Instance.

    Instance Region

    A região onde reside a instância do ApsaraDB for MongoDB de destino.

    Replicate Data Across Alibaba Cloud Accounts

    Selecione No para usar uma instância na conta atual.

    Architecture

    A arquitetura da instância de destino.

    Instance ID

    O ID da instância do ApsaraDB for MongoDB de destino.

    Authentication Database

    O banco de dados de autenticação para o destino. Padrão: admin.

    Database Name

    O nome do banco de dados de destino que receberá os objetos migrados.

    Database Account

    A conta do banco de dados para a instância de destino.

    Database Password

    A senha da conta do banco de dados de destino.

    Encryption

    O método de criptografia da conexão. As opções disponíveis dependem das configurações de Access Method e Architecture. Se o destino for uma instância do ApsaraDB for MongoDB com arquitetura Sharded Cluster, SSL-encrypted estará indisponível.

    Etapa 4: Testar conectividade

    Clique em Test Connectivity and Proceed.

    Certifique-se de que os blocos CIDR dos servidores DTS foram adicionados às configurações de segurança dos bancos de dados de origem e de destino. Consulte Add the CIDR blocks of DTS servers . Se a origem ou o destino for um banco de dados auto-gerenciado não conectado como Alibaba Cloud Instance , clique em Test Connectivity na caixa de diálogo CIDR Blocks of DTS Servers .

    Etapa 5: Configurar objetos de migração

    Na página Configure Objects, configure os seguintes parâmetros:

    Parâmetro

    Descrição

    Migration Types

    Selecione os tipos de migração com base nos seus requisitos. Para realizar apenas migração completa de dados, selecione Schema Migration e Full Data Migration. Para manter o service em execução durante a migração, selecione Schema Migration, Full Data Migration e Incremental Data Migration. Se Schema Migration não for selecionado, crie o banco de dados e as coleções no destino antes de iniciar a tarefa e ative o mapeamento de nomes de objetos em Selected Objects. Se Incremental Data Migration não for selecionado, não grave dados na origem durante a migração.

    Processing Mode of Conflicting Tables

    Precheck and Report Errors: verifica se o destino possui coleções com os mesmos nomes da origem. A pré-verificação falha se existirem duplicatas. Para resolver conflitos de nomenclatura sem excluir ou renomear coleções de destino, use o recurso de mapeamento de nomes de objetos. Consulte Map object names. Ignore Errors and Proceed: ignora a pré-verificação para nomes de coleções duplicados. Durante a migração completa de dados, se um registro tiver a mesma chave primária que um registro existente no destino, o registro existente será mantido. Durante a migração incremental de dados, o registro existente será sobrescrito. Se os esquemas de origem e destino diferirem, colunas específicas podem falhar ao migrar.

    Capitalization of Object Names in Destination Instance

    Controla a capitalização dos nomes de bancos de dados e coleções no destino. Padrão: DTS default policy. Consulte Specify the capitalization of object names in the destination instance.

    Source Objects

    Selecione um ou mais objetos (coleções ou bancos de dados) e clique no ícone 向右小箭头 para adicioná-los aos Selected Objects.

    Selected Objects

    Clique com o botão direito em um objeto para renomeá-lo no destino ou mapeá-lo para um objeto de destino diferente. Consulte Map object names. Clique com o botão direito em um objeto para definir o modo de migração incremental para bancos de dados e coleções. Clique com o botão direito em uma coleção para especificar condições de filtro WHERE para migração completa. Consulte Specify filter conditions. Para remover objetos, clique neles e depois clique no ícone image. Se o mapeamento de nomes de objetos for usado, outros objetos que dependem dos objetos mapeados podem falhar ao migrar.

    Clique em Next: Advanced Settings para configurar o seguinte:

    Parâmetro

    Descrição

    Dedicated Cluster for Task Scheduling

    O DTS agenda tarefas em um cluster compartilhado por padrão. Para maior estabilidade, adquira um cluster dedicado. Consulte What is a DTS dedicated cluster.

    Retry Time for Failed Connections

    A janela de nova tentativa para falhas de conexão após o início da tarefa. Valores válidos: 10–1.440 minutos. Padrão: 720 minutos. Defina como 30 minutos ou mais. Se o DTS reconectar dentro desta janela, a tarefa será retomada. Caso contrário, a tarefa falhará. Quando várias tarefas compartilham o mesmo banco de dados, o tempo de nova tentativa definido mais recentemente se aplica. O DTS cobra pela instância durante a nova tentativa.

    Retry Time for Other Issues

    A janela de nova tentativa para falhas em operações DDL ou DML. Valores válidos: 1–1.440 minutos. Padrão: 10 minutos. Defina como mais de 10 minutos. Deve ser menor que Retry Time for Failed Connections.

    Enable Throttling for Full Data Migration

    Limita o uso de recursos do DTS durante a migração completa de dados. Configure Queries per second (QPS) to the source database, RPS of Full Data Migration e Data migration speed for full migration (MB/s). Disponível apenas quando Full Data Migration estiver selecionado.

    Only one data type for primary key _id in a table of the data to be synchronized

    Especifica se a chave primária _id tem um tipo de dados único em cada coleção. Yes: O DTS ignora a varredura de tipos de dados de chave primária e migra um único tipo por coleção. No: O DTS varre e migra todos os tipos de dados da chave primária. Ative com base nos seus dados. Configuração incorreta pode causar perda de dados. Disponível apenas quando Full Data Migration estiver selecionado.

    Enable Throttling for Incremental Data Migration

    Limita o uso de recursos do DTS durante a migração incremental de dados. Configure RPS of Incremental Data Migration e Data migration speed for incremental migration (MB/s). Disponível apenas quando Incremental Data Migration estiver selecionado.

    Environment Tag

    Uma tag para identificar a instância do DTS. Opcional.

    Configure ETL

    Habilita o recurso de extração, transformação e carga (ETL). Selecione Yes para inserir instruções de processamento de dados no editor de código. Consulte Configure ETL in a data migration or data synchronization task. Selecione No para pular o ETL.

    Monitoring and Alerting

    Configura alertas para a tarefa. Selecione Yes para definir um limiar de alerta e contatos de notificação. Consulte Configure monitoring and alerting when you create a DTS task.

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

    Etapa 6: Executar a pré-verificação

    Clique em Next: Save Task Settings and Precheck.

    Para visualizar os parâmetros da API para esta configuração de tarefa, passe o mouse sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters .

    O DTS executa uma pré-verificação antes do início da migração. A tarefa não pode começar até que a pré-verificação seja aprovada.

    • Se um item de pré-verificação falhar, clique em View Details ao lado dele, resolva o problema e execute a pré-verificação novamente.

    • Se um item de pré-verificação gerar um alerta:

      • Se o alerta não puder ser ignorado, clique em View Details, resolva o problema e execute a pré-verificação novamente.

      • Se o alerta puder ser ignorado, clique em Confirm Alert Details, depois clique em Ignore na caixa de diálogo e clique em OK. Clique em Precheck Again para continuar. Ignorar um alerta pode levar a inconsistência de dados.

    Etapa 7: Adquirir uma instância

    1. Aguarde até que Success Rate atinja 100% e clique em Next: Purchase Instance.

    2. Na página Purchase Instance, configure o seguinte:

      Seção

      Parâmetro

      Descrição

      New Instance Class

      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 da migração. Selecione com base nas suas necessidades. Consulte Instance classes of data migration instances.

    3. Leia e aceite os Data Transmission Service (Pay-as-you-go) Service Terms marcando a caixa de seleção.

    4. Clique em Buy and Start e depois clique em OK na caixa de diálogo de confirmação.

    A tarefa aparece na página Data Migration.

    • Apenas migração completa de dados: a tarefa para automaticamente. O status mostra Completed.

    • Migração incremental de dados: a tarefa é executada continuamente e nunca para automaticamente. O status mostra Running.

    Etapa 8: Criar tarefas para os shards restantes (se aplicável)

    Se Access Method para a origem for Self-managed Database on ECS ou Database Gateway, repita as Etapas 1–7 para cada shard restante.

    Etapa 9: Parar as tarefas de migração

    Full data migration

    Não pare manualmente uma tarefa de migração completa de dados — os dados migrados podem estar incompletos. Aguarde até que a tarefa pare automaticamente.

    Incremental data migration

    A migração incremental de dados não para automaticamente. Pare-a manualmente no momento apropriado, como fora do horário de pico ou antes de alternar cargas de trabalho para a instância de destino.

    1. Aguarde até que Incremental Data Migration apareça na barra de progresso Running e Undelayed apareça em Operation Info. Em seguida, pare de gravar dados no banco de dados de origem por alguns minutos.

    2. Depois que o status de Incremental Data Migration voltar para Undelayed, pare manualmente as tarefas de migração de todos os shards.

    Etapa 10: Alternar cargas de trabalho para a instância de destino

    Após a conclusão da migração e verificação dos dados, alterne suas cargas de trabalho para a instância do ApsaraDB for MongoDB de destino.