Todos os produtos
Search
Central de documentação

Data Transmission Service:Migrar um conjunto de réplicas do MongoDB para um conjunto de réplicas ou cluster com shards

Última atualização: Oct 10, 2026

Este tópico descreve como migrar dados de uma instância de conjunto de réplicas do ApsaraDB for MongoDB para um conjunto de réplicas ou cluster com shards do ApsaraDB for MongoDB usando o Data Transmission service (DTS).

Bancos de dados de origem e destino compatíveis

Banco de dados de origem (conjunto de réplicas)

Banco de dados de destino (conjunto de réplicas ou cluster com shards)

ApsaraDB for MongoDB

ApsaraDB for MongoDB

Banco de dados autogerenciado em uma instância ECS

Banco de dados autogerenciado em uma instância ECS

Banco de dados autogerenciado conectado usando Express Connect, VPN Gateway ou Smart Access Gateway

Banco de dados autogerenciado conectado usando Express Connect, VPN Gateway ou Smart Access Gateway

Banco de dados autogerenciado com um endereço IP público

Banco de dados autogerenciado com um endereço IP público

Este tópico fornece um exemplo de configuração para um conjunto de réplicas de origem do ApsaraDB for MongoDB e uma instância de destino do ApsaraDB for MongoDB (conjunto de réplicas ou cluster com shards). O processo de configuração para outras origens de dados é semelhante.

Pré-requisitos

  • crie uma instância de conjunto de réplicas de origem do ApsaraDB for MongoDB e uma instância de destino de conjunto de réplicas ou cluster com shards do ApsaraDB for MongoDB. Para mais informações, consulte crie a replica set instance e crie a sharded cluster instance.

    Nota

    Para informações sobre as versões compatíveis, consulte Migration solutions overview.

  • A instância de destino do ApsaraDB for MongoDB deve ter 10% a mais de espaço de armazenamento do que a instância de origem do ApsaraDB for MongoDB.

  • Se a instância de destino do ApsaraDB for MongoDB for um cluster com shards, crie os bancos de dados e as coleções que exigem fragmentação, configure o sharding de dados, ative o balanceador e execute o pré-sharding na instância de destino do ApsaraDB for MongoDB de acordo com as necessidades do seu negócio. Para mais informações, consulte Set up data sharding to fully utilize shard performance e How to handle uneven data distribution in a MongoDB sharded cluster.

    Nota

    Configurar o sharding de dados evita que todos os dados sejam migrados para um único shard, garantindo o desempenho ideal do cluster; ativar o balanceador e executar o pré-sharding evita a distorção de dados.

Observações

Tipo

Descrição

Limitações do banco de dados de origem

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

  • As coleções a serem migradas devem ter uma chave primária ou restrição única, e os campos restritos devem conter valores exclusivos. Caso contrário, dados duplicados poderão ser criados no banco de dados de destino.

  • Os nomes dos campos nos dados não devem conter o caractere "." (ponto); caso contrário, poderão ocorrer inconsistências de dados.

  • Se você migrar dados no nível da coleção e edite as coleções, como mapear nomes de coleções, uma única tarefa de migração poderá migrar no máximo 1.000 coleções. Se você exceder esse limite, a tarefa reportará um erro no envio. Nesse caso, divida as coleções em vários lotes e configure uma tarefa separada para cada lote, ou configure uma tarefa para migrar o banco de dados inteiro.

  • Um único documento no banco de dados de origem não pode exceder 16 MB. Caso contrário, a tarefa de migração falhará.

  • Se o banco de dados de origem for um Azure Cosmos DB for MongoDB ou um cluster elástico do Amazon DocumentDB, apenas a migração completa de dados é compatível.

  • Para execute a migração incremental de dados:

    O banco de dados de origem deve ter o oplog ativado com pelo menos sete dias de retenção. Como alternativa, os change streams devem estar ativados, e o DTS deve ser capaz de assinar as alterações de dados do banco de dados de origem nos últimos sete dias usando change streams. Se esses requisitos não forem atendidos, a tarefa de migração poderá falhar porque não conseguirá obter as alterações de dados da origem. Em casos extremos, isso pode levar à inconsistência ou perda de dados. Problemas decorrentes disso não são cobertos pelo service Level Agreement (SLA) do DTS.

    Importante
    • Recomendamos usar o oplog para obter alterações de dados do banco de dados de origem.

    • Apenas o MongoDB 4.0 e versões posteriores são compatíveis com a obtenção de alterações de dados por meio de change streams.

    • Se o banco de dados de origem for um cluster do Amazon DocumentDB (não elástico), ative manualmente os change streams. Ao configurar a tarefa, defina o Migration Method como ChangeStream e a Architecture como Sharded Cluster.

  • Limitações operacionais no banco de dados de origem:

    • Durante as fases de migração de schema e migração completa de dados, não execute alterações de schema em bancos de dados ou coleções, incluindo a atualização de dados em arrays. Tais alterações podem fazer com que a migração falhe ou levar à inconsistência de dados entre os bancos de dados de origem e destino.

    • Se você executar apenas a migração completa de dados, não grave novos dados na instância de origem. Caso contrário, os bancos de dados de origem e destino ficarão inconsistentes. Para manter a consistência de dados em tempo real, selecione Schema Migration, Full Data Migration e Incremental Data Migration.

  • Se uma coleção a ser migrada contiver um índice Time-to-Live (TTL), poderá ocorrer inconsistência de dados ou a latência da instância poderá aumentar.

Outras limitações

  • Se a instância de destino tiver uma arquitetura de cluster com shards:

    • Limpe os documentos órfãos, pois eles podem afetar o desempenho da migração. Se documentos com conflitos de _id forem encontrados durante a migração, poderá ocorrer inconsistência de dados ou falha na tarefa.

    • Antes de iniciar a tarefa, adicione uma chave de shard aos dados de origem para cada coleção com shards no destino. Se não for possível adicionar uma chave de shard aos dados de origem, consulte Migrate data from a MongoDB instance without a shard key to a MongoDB sharded cluster instance.

    • Após o início da tarefa, o comando INSERT deve incluir a chave de shard. O comando UPDATE não pode alterar a chave de shard.

  • Se a instância de destino tiver uma arquitetura de conjunto de réplicas:

    • Quando o Access Method for Express Connect, VPN Gateway, or Smart Access Gateway, Public IP Address ou Cloud Enterprise Network (CEN), defina Domain Name or IP e Port Number para o endereço e a porta do nó primário, ou configure um endereço de conexão de alta disponibilidade. Para mais informações sobre endereços de conexão de alta disponibilidade, consulte crie a Source or Destination Instance for a High-availability MongoDB Database.

    • Quando o Access Method for Self-managed Database on ECS, defina Port Number para a porta do nó primário.

  • O DTS não é compatível com a conexão a um banco de dados MongoDB usando um registro SRV.

  • Mantenha as versões do MongoDB dos bancos de dados de origem e destino consistentes, ou migre de uma versão anterior para uma posterior para garantir a compatibilidade. Migrar de uma versão posterior para uma anterior pode causar problemas de compatibilidade.

  • O DTS não é compatível com a migração de dados dos bancos de dados admin, config ou local.

  • Se a coleção de destino tiver um índice único ou seu atributo capped estiver definido como true, a coleção não será compatível com reprodução simultânea (apenas gravação single-thread é compatível) durante a migração incremental de dados. Isso pode aumentar a latência da tarefa.

  • O DTS não preserva informações de transações. Ele converte transações do banco de dados de origem em instruções individuais no banco de dados de destino.

  • Quando o DTS grava dados em uma coleção de destino, se ocorrer um conflito de chave primária ou chave única, o DTS ignora a instrução de gravação de dados conflitante e retém os dados existentes na coleção de destino.

  • Se o banco de dados de origem for uma versão do MongoDB anterior à 3.6 e o banco de dados de destino for o MongoDB 3.6 ou posterior, a ordem dos campos nos dados migrados poderá diferir da origem. Os pares campo-valor permanecem corretos. Isso é causado por diferenças no plano de execução do mecanismo de banco de dados. Se a lógica do seu aplicativo envolver correspondência de texto em estruturas aninhadas, avalie o impacto potencial dessa alteração na ordem dos campos.

  • Antes de migrar dados, avalie o desempenho dos bancos de dados de origem e destino e execute a migração durante horários de menor movimento. Durante a migração completa de dados, o DTS consome recursos de leitura e gravação, o que pode aumentar a carga do banco de dados.

  • Durante a migração completa de dados, o DTS executa operações INSERT simultâneas, o que pode causar fragmentação nas coleções de destino. Como resultado, as coleções de destino podem ocupar mais espaço de armazenamento do que aquelas na instância de origem.

  • verifique se a precisão de migração que o DTS usa para colunas FLOAT ou DOUBLE atende aos requisitos do seu negócio. O DTS lê valores desses tipos usando ROUND(COLUMN,PRECISION). Se você não definir explicitamente a precisão, o DTS migrará valores FLOAT com precisão de 38 dígitos e valores DOUBLE com precisão de 308 dígitos.

  • O DTS tenta retomar tarefas de migração com falha em até sete dias. Antes do cutover do service para a instância de destino, encerre ou libere a tarefa, ou use o comando revoke para revogar as permissões de gravação da conta que o DTS usa para acessar a instância de destino. Isso evita que os dados de origem substituam os dados na instância de destino caso a tarefa seja retomada automaticamente.

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

  • Use a sintaxe db.$table_name.aggregate([{ $count:"myCount"}]) para consultar a contagem no MongoDB de destino.

  • Certifique-se de que o banco de dados MongoDB de destino não tenha documentos com a mesma chave primária (o campo _id por padrão) do banco de dados de origem. Caso contrário, poderá ocorrer perda de dados. Se tais documentos existirem, exclua aqueles com valores de _id conflitantes do banco de dados de destino antes da migração, desde que isso não afete o seu negócio.

  • Se uma tarefa falhar, a equipe de suporte do DTS tentará restaurá-la em até oito horas. Durante a restauração, eles poderão 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 modifique instance parameters.

  • Se o banco de dados de destino for um cluster com shards do MongoDB, após alternar o seu negócio para este banco de dados, certifique-se de que as operações do seu negócio estejam em conformidade com os requisitos para coleções com shards.

  • Não é possível migrar capped collections quando o banco de dados de origem é o MongoDB 5.0 ou posterior e o banco de dados de destino é uma versão anterior. Isso pode fazer com que a tarefa falhe ou resultar em inconsistência de dados. Isso ocorre porque o comportamento das capped collections mudou no MongoDB 5.0, que permite exclusões explícitas e aumentos no tamanho do documento na atualização. Os kernels de banco de dados anteriores não são compatíveis com esses recursos.

  • Coleções de séries temporais, introduzidas no MongoDB 5.0, não são compatíveis com migração.

  • A sincronização de dados contendo codificação não UTF-8 não é compatível, o que pode levar à inconsistência de dados.

Casos especiais

Se o banco de dados de origem for um banco de dados MongoDB autogerenciado:

  • Um failover primário/secundário no banco de dados de origem durante a migração faz com que a tarefa falhe.

  • O DTS calcula a latência comparando o timestamp do último registro migrado para o destino com o timestamp atual. Se o banco de dados de origem não for atualizado por um longo período, a latência reportada poderá ser imprecisa. Se a tarefa mostrar latência excessiva, execute uma pequena atualização no banco de dados de origem e atualize o valor da latência.

Nota

Se você migrar um banco de dados inteiro, também poderá criar uma tabela de heartbeat que seja atualizada em intervalos regulares, como a cada segundo.

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, você é cobrado pelo tráfego de internet. Para mais informações, consulte Billing overview.

Migração incremental de dados

Pago. Para mais informações, consulte Billing overview.

Tipos de migração

Tipo

Descrição

migração de schema

Migra o schema dos objetos de migração do ApsaraDB for MongoDB de origem para o ApsaraDB for MongoDB de destino.

Nota

A migração de schema é compatível com bancos de dados, coleções e índices.

migração completa de dados

Migra todos os dados existentes dos objetos de migração do ApsaraDB for MongoDB de origem para o ApsaraDB for MongoDB de destino.

Nota

A migração completa de dados é compatível com dados em bancos de dados e coleções.

migração incremental de dados

Além da migração completa, você pode migrar atualizações incrementais do ApsaraDB for MongoDB de origem para o ApsaraDB for MongoDB de destino.

Oplog

A migração incremental não é compatível com bancos de dados criados após o início da tarefa. As seguintes atualizações incrementais são compatíveis:

  • CREATE COLLECTION e CREATE INDEX

  • DROP DATABASE, DROP COLLECTION e DROP INDEX

    Nota

    Operações RENAME COLLECTION que incluem a opção dropTarget definida como true não são compatíveis.

  • RENAME COLLECTION

  • Inserção, atualização e exclusão de documentos em uma coleção.

    Nota

    Para atualizações incrementais de documentos, apenas as alterações feitas usando o comando $set são replicadas.

Change stream

As seguintes atualizações incrementais são compatíveis:

  • DROP DATABASE e DROP COLLECTION

  • RENAME COLLECTION

    Nota

    Operações RENAME COLLECTION que incluem a opção dropTarget definida como true não são compatíveis.

  • Inserção, atualização e exclusão de documentos em uma coleção.

    Nota

    Para atualizações incrementais de documentos, apenas as alterações feitas usando o comando $set são replicadas.

Permissões de conta do banco de dados

Banco de dados

Migração de schema

Migração completa de dados

Migração incremental de dados

Instância do ApsaraDB for MongoDB de origem

Permissão de leitura no banco de dados a ser migrado e no banco de dados config.

Permissão de leitura no banco de dados a ser migrado, no banco de dados admin e no banco de dados local.

Instância do ApsaraDB for MongoDB de destino

dbAdminAnyDatabase, readWrite no banco de dados de destino e read no banco de dados local.

Para crie contas de banco de dados e conceder permissões para as instâncias de origem e destino do ApsaraDB for MongoDB, consulte gerencie MongoDB database users with DMS.

Nota

Se você usar ChangeStream como o método de migração incremental, a conta do banco de dados de origem requer permissões de leitura de Change Streams em toda a instância (como readAnyDatabase). Se a origem for uma instância do ApsaraDB for MongoDB com uma conta personalizada, você também deve conceder à conta permissão de leitura no banco de dados admin. Para mais detalhes, consulte Permissions of the root account specified during instance creation.

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.

    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 com base no modo e no 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 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 destino.

    Aviso

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

    Categoria

    Parâmetro

    Descrição

    N/D

    Task Name

    O DTS gera automaticamente um nome de tarefa. Recomendamos que você especifique 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 foi added to the system (criada ou salva), selecione a instância de banco de dados desejada na lista suspensa. As informações do banco de dados abaixo serão configuradas automaticamente.

      Nota

      No console do DMS, este parâmetro é nomeado Select a DMS database instance..

    • Se você não registrou a instância do 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 MongoDB.

    Access Method

    Selecione Cloud instance.

    Instance Region

    Selecione a região onde a instância do ApsaraDB for MongoDB de origem está localizada.

    Replicate Data Across Alibaba Cloud Accounts

    Neste exemplo, é usada uma instância de banco de dados na conta atual da Alibaba Cloud. Selecione No.

    Architecture

    Selecione Replica Set.

    • Replica Set: Esta arquitetura usa vários nós para garantir alta disponibilidade e habilitar a divisão de leitura/gravação. Para mais informações, consulte Replica set architecture.

    • Sharded Cluster: Esta arquitetura consiste em componentes mongos, shard e ConfigServer. Você pode personalizar o número e as configurações dos nós mongos e shard. Para mais informações, consulte Sharded cluster architecture.

    Migration Method

    Selecione um método para migração incremental de dados com base nos seus requisitos.

    • Oplog (Recomendado):

      Esta opção está disponível se um oplog estiver ativado para o banco de dados de origem.

      Nota

      Um oplog é ativado por padrão para bancos de dados MongoDB autogerenciados e instâncias do ApsaraDB for MongoDB. Este método oferece menor latência para migração incremental de dados devido à extração de logs mais rápida. Portanto, recomendamos selecionar Oplog.

    • ChangeStream: Esta opção está disponível se os Change Streams estiverem ativados para o banco de dados de origem.

      Nota
      • Se o banco de dados de origem for uma instância do Amazon DocumentDB (cluster não elástico), você só poderá selecionar ChangeStream.

      • Se você definir Architecture como Sharded Cluster para o banco de dados de origem, não precisará inserir um Shard account ou Shard password.

    Instance ID

    Selecione o ID da instância do ApsaraDB for MongoDB de origem.

    Authentication Database

    insira o nome do banco de dados ao qual a conta do banco de dados da instância do ApsaraDB for MongoDB de origem pertence. O valor padrão é admin.

    Database Account

    insira a conta do banco de dados da instância do ApsaraDB for MongoDB de origem. Para informações sobre os requisitos de permissão, consulte Database account permissions.

    Database Password

    insira a senha da conta do banco de dados.

    Encryption

    O DTS é compatível com três métodos de conexão: Non-encrypted, SSL-encrypted e Mongo Atlas SSL. As opções de Encryption variam com base no Access Method e na Architecture selecionados. As opções exibidas no console prevalecem.

    Nota
    • Um banco de dados MongoDB onde a Architecture é Sharded Cluster e o Migration Method é Oplog não é compatível com SSL-encrypted.

    • Se a origem for um banco de dados MongoDB autogerenciado (Access Method não é Alibaba Cloud Instance) com uma arquitetura Replica Set, e você selecionar SSL-encrypted, o DTS também permitirá que você faça upload de um certificado CA para verificar a conexão.

    Destination Database

    Select Existing Connection

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

      Nota

      No console do DMS, este parâmetro é nomeado Select a DMS database instance..

    • Se você não registrou a instância do 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 MongoDB.

    Access Method

    Selecione Cloud instance.

    Instance Region

    Selecione a região onde a instância do ApsaraDB for MongoDB de destino está localizada.

    Replicate Data Across Alibaba Cloud Accounts

    Neste exemplo, é usada uma instância de banco de dados na conta atual da Alibaba Cloud. Selecione No.

    Architecture

    Selecione uma arquitetura com base nos requisitos do seu negócio. Valores válidos:

    • Replica Set: Esta arquitetura usa vários nós para garantir alta disponibilidade e habilitar a divisão de leitura/gravação. Para mais informações, consulte Replica set architecture.

    • Sharded Cluster: Esta arquitetura consiste em componentes mongos, shard e ConfigServer. Você pode personalizar o número e as configurações dos nós mongos e shard. Para mais informações, consulte Sharded cluster architecture.

    Instance ID

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

    Authentication Database

    insira o nome do banco de dados ao qual a conta do banco de dados da instância do ApsaraDB for MongoDB de destino pertence. O valor padrão é admin.

    Database Account

    insira a conta do banco de dados da instância do ApsaraDB for MongoDB de destino. Para informações sobre os requisitos de permissão, consulte Database account permissions.

    Database Password

    insira a senha da conta do banco de dados.

    Encryption

    O DTS é compatível com três métodos de conexão: Non-encrypted, SSL-encrypted e Mongo Atlas SSL. As opções de Encryption variam com base no Access Method e na Architecture selecionados. As opções exibidas no console prevalecem.

    Nota
    • Bancos de dados MongoDB com uma Architecture de Sharded Cluster não são compatíveis com SSL-encrypted.

    • Se o destino for um banco de dados MongoDB autogerenciado (Access Method não é Alibaba Cloud Instance) com um Replica Set, e você selecionar SSL-encrypted, o DTS também permitirá que você faça upload de um certificado CA para verificar a conexão.

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

    Nota
    • Certifique-se de que os blocos CIDR de endereços IP dos servidores do DTS foram adicionados às configurações de segurança dos bancos de dados de origem e destino para permitir o acesso dos servidores do DTS. Isso pode ser feito automática ou manualmente. Para mais informações, consulte Add the IP address CIDR blocks of DTS servers to a whitelist.

    • Se o banco de dados de origem ou destino for um banco de dados autogerenciado (onde 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.

  5. Configure os objetos da tarefa.

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

    Parâmetro

    Descrição

    Migration Types

    • Se você precisar executar apenas uma migração completa, selecione Schema Migration e Full Data Migration.

    • Para executar 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, deverá garantir que exista 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 nomes de objetos 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.

    Para mais informações, consulte Migration types.

    Processing Mode of Conflicting Tables

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

      Nota

      Se uma coleção 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 coleção no banco de dados de destino. Para mais informações, consulte Object name mapping.

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

      Aviso

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

      • Se 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, o registro no banco de dados de destino será mantido. O registro do banco de dados de origem não será migrado para o banco de dados de destino.

      • A inicialização de dados pode falhar, apenas alguns dados podem ser migrados ou a migração pode falhar.

    Capitalization of Object Names in Destination Instance

    Você pode configurar a política de maiúsculas e minúsculas para os nomes dos bancos de dados e coleções migrados na instância de destino. Por padrão, DTS default policy é selecionado. Você também pode escolha alinhar com as políticas padrão do banco de dados de origem ou destino. Para mais informações, consulte Object name case policy for the destination.

    Source Objects

    Na caixa Source Objects, clique no objeto que deseja migrar e, em seguida, clique em 向右小箭头 para movê-lo para a caixa Selected Objects.

    Nota

    Você pode selecionar objetos no nível DATABASE ou COLLECTION.

    Selected Objects

    • Para definir o nome de um objeto de migração na instância de destino, ou para especificar o objeto que receberá dados na instância de destino, clique com o botão direito do mouse no objeto de migração na caixa Selected Objects para fazer alterações. Para mais informações, consulte Object name mapping.

    • Para remover um objeto de migração selecionado, clique no objeto na caixa Selected Objects e, em seguida, clique em image para movê-lo para a caixa Source Objects.

    Nota
    • Para selecionar operações de migração incremental no nível do banco de dados ou coleção, clique com o botão direito do mouse no objeto de migração na caixa Selected Objects e faça sua seleção na caixa de diálogo que aparece.

    • Para definir condições para filtrar dados (compatível durante a migração completa de dados, mas não na migração incremental de dados), clique com o botão direito do mouse na coleção na caixa Selected Objects e configure as opções na caixa de diálogo que aparece. Para obter instruções, consulte Filter task data with an SQL condition.

    • Se você usar o recurso de mapeamento de nomes de objetos para especificar um banco de dados ou coleção para receber dados, a migração de outros objetos que dependem deste objeto poderá falhar.

    1. 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. Você não precisa selecionar um. Se desejar tarefas mais estáveis, poderá adquirir um dedicated cluster para executar tarefas de migração do DTS.

      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 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 de 10 a 1440 minutos. Recomendamos 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 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 você é cobrado 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 destino.

      Retry Time for Other Issues

      Após o início da tarefa de migração, se ocorrer um problema de não 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 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 de 1 a 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 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, você pode ativar o limitador para a tarefa de migração completa. Você pode 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 para Migration Types.

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

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

      Nos dados a serem migrados, o tipo de dados da chave primária _id é uniforme dentro de uma única coleção?

      Importante
      • Selecione uma opção com base nos seus requisitos. Caso contrário, poderá ocorrer perda de dados.

      • Este parâmetro está disponível apenas se você selecionar Full Data Migration para Migration Types.

      • Yes: O tipo de dados é único. Durante a migração completa de dados, o DTS não verifica os tipos de dados das chaves primárias nos dados de origem. Para uma única coleção, o DTS migra apenas os dados correspondentes a um tipo de dados de chave primária.

      • No: O tipo de dados não é único. Durante a migração completa de dados, o DTS verifica os tipos de dados das chaves primárias nos dados de origem e migra todos os dados.

      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. Você pode 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 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

      Você pode selecionar uma tag de ambiente para identificar a instância. Isso é opcional para este exemplo.

      Configure ETL

      Com base nas necessidades do seu negócio, selecione se deseja configurar o ETL feature para processar dados.

      • Yes: Configura o recurso ETL. Você também deve inserir data processing statements na caixa de texto.

      • No: Não configura o recurso ETL.

      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 um alerta.

      • 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 enviará uma notificação de alerta.

    2. Clique em Next Data Verification para configurar uma tarefa de verificação de dados.

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

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

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

    • Se você não precisar visualizar ou já terminou 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 executa uma pré-verificação. A tarefa só é iniciada 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 com base no aviso e, em seguida, 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 no aviso e, em seguida, execute a pré-verificação novamente.

      • Para itens de verificação que podem ser ignorados, clique em Confirm Alert Details, Ignore, OK e Precheck Again para pular o item de aviso e executar a pré-verificação novamente. Se você optar por ignorar um aviso, isso poderá 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 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 é default resource group. 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 da migração. Você pode selecionar uma especificação com base no cenário do seu negócio. 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. 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 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.

Perguntas frequentes

Por que encontro latência de tarefa e inconsistência de dados mesmo quando não há gravações do aplicativo?

  • Causa: Este problema ocorre devido a um conflito entre o mecanismo de exclusão automática de um índice TTL em uma coleção do MongoDB e o mecanismo de sincronização de dados do DTS. Esse conflito pode levar à latência da tarefa e à inconsistência de dados na sua tarefa de sincronização/migração.

    • DELETEs redundantes reduzem a eficiência: Quando o índice TTL de origem exclui dados expirados, ele grava um registro DELETE no Oplog. O DTS reproduz esse DELETE no destino. Se o índice TTL de destino já tiver excluído os mesmos dados, o MongoDB retornará uma contagem de linhas afetadas inesperada, acionando o tratamento de exceções e retardando a migração.

    • Inconsistência de dados devido à exclusão assíncrona de TTL: Os índices TTL não excluem dados em tempo real. Dados expirados ainda podem existir na origem enquanto o destino já os excluiu, causando inconsistência.

      Exemplo:

      O Oplog ou ChangeStream do MongoDB registra apenas os campos atualizados para uma operação UPDATE, não o documento completo. Se um UPDATE não conseguir encontrar os dados de destino no destino, o DTS ignora a operação.

      Tempo

      Instância de origem

      Instância de destino

      1

      O service insere dados

      2

      O DTS sincroniza a operação INSERT

      3

      Os dados expiraram, mas ainda não foram excluídos pelo índice TTL

      4

      O service atualiza os dados (por exemplo, atualiza o campo do índice TTL para alterar o tempo de expiração)

      5

      O índice TTL exclui os dados

      6

      O DTS sincroniza o UPDATE, mas os dados não são encontrados. A operação é ignorada.

      Como resultado, este documento está ausente na instância MongoDB de destino.

  • Solução: Para resolver isso, modifique temporariamente o tempo de expiração do índice TTL no destino durante a tarefa de sincronização/migração. Isso garante tanto a eficiência da sincronização quanto a consistência dos dados. Para etapas detalhadas, consulte Best practices for synchronizing or migrating collections with TTL indexes from a MongoDB source.