Todos os produtos
Search

Este produto

    ApsaraDB for MongoDB:Sincronização unidirecional para clusters com sharding

    Central de documentação

    ApsaraDB for MongoDB:Sincronização unidirecional para clusters com sharding

    Última atualização: Aug 20, 2026

    O Data Transmission Service (DTS) permite sincronizar dados de um cluster com sharding do MongoDB para um replica set ou outro cluster com sharding. Este tópico demonstra como sincronizar dados entre instâncias do ApsaraDB for MongoDB.

    Pré-requisitos

    • Crie uma instância de destino do ApsaraDB for MongoDB (replica set ou cluster com sharding). Para mais informações, consulte Create a replica set instance ou Create a sharded cluster instance.

      Importante

      • O espaço de armazenamento da instância de destino do ApsaraDB for MongoDB deve ser pelo menos 10% maior que o da instância de origem do ApsaraDB for MongoDB.

      • Para versões compatíveis, consulte Data synchronization scenarios.

    • Para uma instância de cluster com sharding de origem do ApsaraDB for MongoDB, solicite um endpoint para cada nó de shard e garanta que todos os nós de shard usem a mesma conta e senha. Para mais informações, consulte Apply for a shard endpoint.

    • Se o destino for uma instância de cluster com sharding, crie os bancos de dados e as coleções que serão fragmentados na instância de destino do ApsaraDB for MongoDB (cluster com sharding), configure o sharding de dados, ative o balancer e execute o pré-sharding conforme suas necessidades de negócio. Para mais informações, consulte Configure sharding to maximize shard performance e How do I handle uneven data distribution in a sharded MongoDB cluster?.

      Nota

      • Configurar o sharding de dados evita que todos os dados sejam sincronizados em um único shard, prevenindo gargalos de desempenho. Ativar o balancer e realizar o pré-sharding ajuda a evitar distorção de dados.

      • Este tópico apresenta um exemplo de configuração de tarefa DTS antes da compra. Nesse cenário, não é necessário especificar o número de shards na instância de origem do ApsaraDB for MongoDB (cluster com sharding).

        Caso compre uma tarefa DTS antes de configurá-la, especifique o número correto de shards no momento da compra.

    Precauções

    Tipo

    Descrição

    Limites dos bancos de dados de origem e destino

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

    • As coleções a serem sincronizadas devem ter uma chave primária ou restrição UNIQUE, e os valores dos campos devem ser únicos. Caso contrário, podem surgir dados duplicados no banco de dados de destino.

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

    • O campo _id nas coleções a serem sincronizadas deve ter valores únicos. Caso contrário, pode ocorrer inconsistência de dados.

    • Se você sincronizar no nível de coleção e precisar editar objetos (como renomear coleções), uma única tarefa de sincronização suporta até 1.000 coleções. Se exceder esse limite, a tarefa falhará com um erro após o envio. Para resolver, divida as coleções em lotes e configure várias tarefas, ou configure uma tarefa de sincronização de banco de dados completo.

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

    • O banco de dados de origem não pode ser Azure Cosmos DB for MongoDB nem Amazon DocumentDB (elastic cluster).

    • O banco de dados de origem deve ter o Oplog ativado e retê-lo por pelo menos sete dias. Alternativamente, ative o Change Streams e garanta que o DTS possa assinar alterações de dados dos últimos sete dias via Change Streams. Caso contrário, o DTS pode falhar ao capturar alterações de dados, causando falha na tarefa. Em casos extremos, isso pode causar inconsistência ou perda de dados. Esses problemas não são cobertos pelo Acordo de Nível de Serviço (SLA) do DTS.

      Importante

      • Recomendamos usar o Oplog para capturar alterações de dados.

      • Somente o MongoDB 4.0 e versões posteriores suportam Change Streams. O Change Streams não suporta sincronização bidirecional.

      • Se o banco de dados de origem for Amazon DocumentDB (non-elastic cluster), ative manualmente o Change Streams. Ao configurar a tarefa, defina Migration Method como ChangeStream e defina Architecture como Sharded Cluster.

    • Se o DTS usar Oplog para sincronização incremental, o dimensionamento do número de shards não é suportado para um cluster com sharding do MongoDB de origem. Caso contrário, as tarefas do DTS podem falhar e causar inconsistência de dados.

    • Se a instância de origem for um cluster com sharding do MongoDB autogerenciado:

      • Access Method suporta apenas Express Connect, VPN Gateway, or Smart Access Gateway e Cloud Enterprise Network (CEN).

      • Se a versão do seu MongoDB for 8,0 ou posterior e Migration Method for Oplog, garanta que a conta Shard usada pela tarefa de sincronização tenha a permissão directShardOperations. Adicione essa permissão usando o comando db.adminCommand({ grantRolesToUser: "username", roles: [{ role: "directShardOperations", db: "admin"}]}).

        Nota

        Substitua username no comando pela conta Shard usada pela tarefa de sincronização.

      • Se Migration Method for Oplog e a tarefa incluir sincronização completa de dados, garanta que a conta Mongos do seu cluster com sharding do MongoDB de origem tenha permissão para executar o comando db.runCommand({"balancerStatus":1}). O DTS verifica se o Balancer está desativado usando este comando durante a pré-verificação.

    • O número de nós Mongos na instância de cluster com sharding do MongoDB de origem não pode exceder 10.

    • Se as coleções a serem sincronizadas contiverem índices TTL, pode ocorrer inconsistência ou latência de dados.

    • Garanta que não existam documentos órfãos nas instâncias de origem e destino. Caso contrário, pode ocorrer inconsistência de dados ou falha na tarefa. Para mais informações, consulte orphaned documents e How to clean orphaned documents in MongoDB (sharded cluster architecture).

    • Limites de operação do banco de dados de origem:

      • Durante a sincronização de schema e a sincronização completa de dados, não altere o schema de bancos de dados ou coleções (incluindo atualizações de dados do tipo array). Caso contrário, a tarefa de sincronização pode falhar ou causar inconsistência de dados entre os bancos de origem e destino.

      • Se você executar apenas a sincronização completa de dados, não grave novos dados na instância de origem. Caso contrário, pode ocorrer inconsistência de dados entre os bancos de origem e destino.

      • Enquanto a instância de sincronização estiver em execução, não execute comandos que alterem a distribuição de dados nos objetos a serem sincronizados no banco de dados de origem (por exemplo, shardCollection, reshardCollection, unshardCollection, moveCollection ou movePrimary). Caso contrário, pode ocorrer inconsistência de dados.

    • Se o Balancer no banco de dados de origem estiver balanceando dados, pode ocorrer latência.

    • O DTS não suporta conexão com bancos de dados MongoDB usando endereços SRV.

    • Se o banco de dados de origem for MongoDB 5,0 ou posterior e a versão do banco de dados de destino for anterior à 5,0, não é possível sincronizar capped collections. Se tentar sincronizá-las, a tarefa falhará ou ocorrerá inconsistência de dados entre os bancos de origem e destino. Isso ocorre porque, a partir do MongoDB 5,0, o comportamento das capped collections mudou para permitir operações como exclusão explícita e aumento do tamanho do documento durante atualizações, e versões anteriores do kernel do banco de dados não suportam esses novos recursos.

    Outros limites

    • Antes de iniciar a tarefa, adicione a chave de shard usada pelo destino aos dados na origem. Após iniciar a tarefa, as instruções INSERT para os dados a serem sincronizados devem incluir a chave de shard. Instruções UPDATE não podem modificar a chave de shard.

    • Recomendamos usar a mesma versão do MongoDB para os bancos de dados de origem e destino. Ou use uma versão superior no destino para garantir compatibilidade. Sincronizar de uma versão superior para uma inferior pode causar problemas de compatibilidade.

    • O DTS não suporta sincronização de dados dos bancos de dados admin, config e local.

    • Informações de transação não são preservadas. Transações no banco de dados de origem tornam-se registros individuais no banco de dados de destino.

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

    • Se a versão do MongoDB de origem for anterior à 3,6 e a versão do MongoDB de destino for 3,6 ou posterior, diferenças nos planos de execução podem causar ordenação inconsistente de campos nos dados sincronizados. As relações campo-valor permanecem inalteradas. Se o seu negócio usar consultas de correspondência de texto em estruturas aninhadas, avalie o impacto da ordenação inconsistente de campos.

    • Avalie o desempenho dos bancos de dados de origem e destino antes da sincronização. Execute a sincronização fora dos horários de pico. Caso contrário, a inicialização completa de dados consome recursos de leitura e gravação, aumentando a carga do banco de dados.

    • A inicialização completa executa operações INSERT simultaneamente. Isso cria fragmentação na coleção do banco de dados de destino. Após a inicialização completa, o espaço da coleção na instância de destino será maior do que na instância de origem.

    • Se a coleção de destino tiver um índice único ou sua propriedade capped estiver definida como true, a reprodução simultânea não é suportada durante a sincronização incremental. Apenas gravações em thread única são permitidas. Isso pode aumentar a latência da tarefa.

    • Como o DTS grava dados simultaneamente, o espaço de armazenamento usado pelo destino é 5% a 10% maior que o da origem.

    • Para obter a contagem de documentos no MongoDB de destino, use a sintaxe db.$table_name.aggregate([{ $count:"myCount"}]).

    • Garanta que o MongoDB de destino não tenha a mesma chave primária (padrão é _id) que a origem. Caso contrário, pode ocorrer perda de dados. Se o destino tiver a mesma chave primária, limpe os dados relacionados no destino sem afetar seu negócio (exclua documentos com o mesmo valor de _id no destino).

    • Desative o Balancer no banco de dados MongoDB de origem durante a sincronização completa. Mantenha-o desativado até que todas as subtarefas alcancem a fase incremental. Caso contrário, pode ocorrer inconsistência de dados. Para mais informações sobre como gerenciar o Balancer, consulte Manage the MongoDB Balancer.

    • Se você não precisar do recurso de sincronização de schema fornecido pelo DTS — por exemplo, se o particionamento de dados já estiver configurado no destino — não selecione Configure Objects e, em seguida, selecione Synchronization Types e Schema Synchronization. Caso contrário, conflitos de sharding podem levar a inconsistência de dados ou falha na tarefa.

    • Se você alternar o tráfego para o banco de dados MongoDB de destino, garanta que o comportamento do seu negócio atenda aos requisitos do MongoDB para coleções com sharding.

    • O DTS não suporta sincronização de coleções de séries temporais introduzidas no MongoDB 5,0 e versões posteriores.

    • 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 Modify instance parameters.

    Faturamento

    Tipo de sincronização

    Preço

    Sincronização de schema e sincronização completa de dados

    Gratuito.

    Sincronização incremental de dados

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

    Topologias de sincronização unidirecional

    O DTS suporta apenas sincronização unidirecional de dados entre duas instâncias de cluster com sharding do ApsaraDB for MongoDB. A sincronização entre múltiplas instâncias do ApsaraDB for MongoDB não é suportada.

    Tipos de sincronização

    Tipo

    Descrição

    Sincronização de schema

    Sincroniza o schema dos objetos de sincronização no ApsaraDB for MongoDB de origem para o ApsaraDB for MongoDB de destino.

    Sincronização completa de dados

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

    Nota

    A sincronização completa de dados é suportada para bancos de dados e coleções.

    Sincronização incremental de dados

    Com base na sincronização completa de dados, as atualizações incrementais do ApsaraDB for MongoDB de origem são sincronizadas para o ApsaraDB for MongoDB de destino.

    Oplog

    A sincronização incremental de dados não replica bancos de dados criados após o início da tarefa. As seguintes alterações são replicadas:

    • CREATE COLLECTION e CREATE INDEX

    • DROP DATABASE, DROP COLLECTION e DROP INDEX

    • RENAME COLLECTION

      Nota

      A operação RENAME COLLECTION não é replicada se a opção dropTarget estiver definida como true.

    • Inserções, atualizações e exclusões de documentos dentro de uma coleção.

      Nota

      Para atualizações de documentos, replica apenas operações que usam o comando $set.

    Change stream

    As seguintes alterações são replicadas:

    • DROP DATABASE e DROP COLLECTION

    • RENAME COLLECTION

      Nota

      A operação RENAME COLLECTION não é replicada se a opção dropTarget estiver definida como true.

    • Inserções, atualizações e exclusões de documentos dentro de uma coleção.

      Nota

      Para atualizações de documentos, replica apenas operações que usam o comando $set.

    Limpar documentos órfãos

    Limpe os documentos órfãos do banco de dados MongoDB de origem antes de migrar os dados.

    Importante

    A falha em limpar documentos órfãos afeta o desempenho da migração e pode causar erros de migração de dados devido a conflitos de _id.

    ApsaraDB for MongoDB

    Nota

    Executar o script de limpeza em uma instância com versão principal anterior ao MongoDB 4.2 ou versão secundária anterior à 4.0.6 causa um erro. Para visualizar a versão atual da sua instância, consulte MongoDB minor versions. Para atualizar a versão principal ou secundária, consulte Upgrade the major version of a database e Upgrade the minor version of a database.

    Use o comando cleanupOrphaned para limpar documentos órfãos. O procedimento difere ligeiramente para MongoDB 4.4 e posteriores e para MongoDB 4.2 e anteriores.

    MongoDB 4.4 e posteriores

    1. Em um servidor que possa se conectar à sua instância de cluster com sharding, crie um script JavaScript (JS) chamado cleanupOrphaned.js.

      Nota

      Este script limpa documentos órfãos de todas as coleções em vários bancos de dados em vários shards. Se precisar limpar documentos órfãos de uma coleção específica, modifique o script JS.

      // List of shard names
var shardNames = ["shardName1", "shardName2"];
// List of databases
var databasesToProcess = ["database1", "database2", "database3"];
shardNames.forEach(function(shardName) {
    // Iterate over the specified list of databases
    databasesToProcess.forEach(function(dbName) {
        var dbInstance = db.getSiblingDB(dbName);
        // Get the names of all collections in the database instance
        var collectionNames = dbInstance.getCollectionNames();
        // Iterate over each collection
        collectionNames.forEach(function(collectionName) {
            // The full collection name
            var fullCollectionName = dbName + "." + collectionName;
            // Build the cleanupOrphaned command
            var command = {
                runCommandOnShard: shardName,
                command: { cleanupOrphaned: fullCollectionName }
            };
            // Execute the command
            var result = db.adminCommand(command); 
            if (result.ok) {
                print("Cleaned up orphaned documents for collection " + fullCollectionName + " on shard " + shardName);
                printjson(result);
            } else {
                print("Failed to clean up orphaned documents for collection " + fullCollectionName + " on shard " + shardName);
            }
        });
    });
});

      No script, modifique os valores dos parâmetros shardNames e databasesToProcess:

      • shardNames: Um array de IDs dos shards dos quais limpar documentos órfãos. Obtenha os IDs dos shards na Lista de Shards na página de Informações Básicas da instância. Por exemplo, d-bp15a3796d3a****.

      • databasesToProcess: Um array de nomes de bancos de dados dos quais limpar documentos órfãos.

    2. No diretório onde o script cleanupOrphaned.js está localizado, execute o seguinte comando para limpar documentos órfãos.

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

      Parâmetro

      Descrição

      <Mongoshost>

      O endereço de conexão do nó mongos da instância de cluster com sharding. Exemplo: s-bp14423a2a51****.mongodb.rds.aliyuncs.com.

      <Primaryport>

      O número da porta do nó mongos da instância de cluster com sharding. O valor padrão é 3717.

      <database>

      O nome do banco de dados de autenticação. Este é o banco de dados ao qual a conta do banco de dados pertence.

      <username>

      A conta do banco de dados.

      <password>

      A senha da conta do banco de dados.

      output.txt

      O arquivo de saída para os resultados da execução.

    MongoDB 4.2 e anteriores

    1. Em um servidor que possa se conectar à sua instância de cluster com sharding, crie um script JS chamado cleanupOrphaned.js.

      Nota

      Este script limpa documentos órfãos de uma coleção especificada em um banco de dados especificado em vários shards. Para limpar documentos órfãos de várias coleções, modifique o parâmetro fullCollectionName e execute o script várias vezes, ou modifique o script para iterar pelas coleções.

      function cleanupOrphanedOnShard(shardName, fullCollectionName) {
    var nextKey = { };
    var result;
    while ( nextKey != null ) {
        var command = {
            runCommandOnShard: shardName,
            command: { cleanupOrphaned: fullCollectionName, startingFromKey: nextKey }
        };
        result = db.adminCommand(command);
        printjson(result);
        if (result.ok != 1 || !(result.results.hasOwnProperty(shardName)) || result.results[shardName].ok != 1 ) {
            print("Unable to complete at this time: failure or timeout.")
            break
        }
        nextKey = result.results[shardName].stoppedAtKey;
    }
    print("cleanupOrphaned done for coll: " + fullCollectionName + " on shard: " + shardName)
}
var shardNames = ["shardName1", "shardName2", "shardName3"]
var fullCollectionName = "database.collection"
shardNames.forEach(function(shardName) {
    cleanupOrphanedOnShard(shardName, fullCollectionName);
});

      No script, modifique os valores dos parâmetros shardNames e fullCollectionName:

      • shardNames: Um array de IDs dos shards dos quais limpar documentos órfãos. Obtenha os IDs dos shards na Lista de Shards na página de Informações Básicas da instância. Por exemplo, d-bp15a3796d3a****.

      • fullCollectionName: O nome da coleção da qual limpar documentos órfãos, no formato database.collection.

    2. No diretório onde o script cleanupOrphaned.js está localizado, execute o seguinte comando para limpar documentos órfãos.

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

      Parâmetro

      Descrição

      <Mongoshost>

      O endereço de conexão do nó mongos da instância de cluster com sharding. Exemplo: s-bp14423a2a51****.mongodb.rds.aliyuncs.com.

      <Primaryport>

      O número da porta do nó mongos da instância de cluster com sharding. O valor padrão é 3717.

      <database>

      O nome do banco de dados de autenticação. Este é o banco de dados ao qual a conta do banco de dados pertence.

      <username>

      A conta do banco de dados.

      <password>

      A senha da conta do banco de dados.

      output.txt

      O arquivo de saída para os resultados da execução.

    MongoDB autogerenciado

    1. Em um servidor que possa se conectar ao seu banco de dados MongoDB autogerenciado, baixe o arquivo de script cleanupOrphaned.js.

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

    2. Modifique o arquivo de script cleanupOrphaned.js. Substitua test pelo nome do banco de dados do qual deseja limpar documentos órfãos.

      Importante

      Se tiver vários bancos de dados, repita a Etapa 2 e a Etapa 3 para cada banco de dados.

      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 o seguinte comando para limpar documentos órfãos de todas as coleções no banco de dados especificado em um shard.

      Nota

      Repita esta etapa para cada shard.

      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 nome do banco de dados de autenticação. Este é o banco de dados ao qual a conta do banco de dados pertence.

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

      • <password>: A senha da conta.

      Exemplo:

      Neste exemplo, o banco de dados MongoDB autogerenciado possui três shards. Execute o comando para cada shard para limpar os documentos órfãos.

      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

    Procedimento

    Importante

    Este tópico usa um exemplo de configuração de tarefa DTS antes da compra, onde não é necessário especificar o número de shards para o cluster com sharding de origem do ApsaraDB for MongoDB.

    Caso compre uma tarefa DTS antes de configurá-la, especifique o número correto de shards no momento da compra.

    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 dependendo do modo e 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 e configure os bancos de dados de origem e destino.

      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 an existing DMS database instance. (Optional. If you have not registered a DMS database instance, ignore this option and configure database settings in the section below.) (Opcional. Se não tiver criado uma conexão, ignore esta opção e configure as informações do banco de dados diretamente na seção abaixo.)

      Selecione uma instância existente conforme necessário.

      • Se usar uma instância existente, as informações do banco de dados serão preenchidas automaticamente. Não é necessário inseri-las novamente.

      • Se não usar uma instância existente, insira as seguintes informações do banco de dados.

      Database Type

      Selecione MongoDB.

      Access Method

      Selecione Alibaba Cloud Instance.

      Instance Region

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

      Replicate Data Across Alibaba Cloud Accounts

      Este exemplo mostra como sincronizar dados dentro da mesma conta Alibaba Cloud. Selecione No.

      Architecture

      Selecione Sharded Cluster.

      Migration Method

      Selecione um método para sincronização incremental de dados com base nas suas necessidades.

      • Oplog (Recomendado):

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

        Nota

        O 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 tarefas de sincronização incremental porque os logs são recuperados mais rapidamente. Recomendamos selecionar Oplog.

      • ChangeStream:

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

        Nota

        • Se o banco de dados de origem for uma instância do Amazon DocumentDB (non-elastic cluster), selecione apenas ChangeStream.

        • Se definir Architecture do banco de dados de origem como Sharded Cluster, não é necessário especificar Shard account e Shard password.

      Instance ID

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

      Database Name

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

      Database Account

      Insira a conta do banco de dados da instância de origem do ApsaraDB for MongoDB. Esta conta deve ter permissões de leitura no banco de dados a ser sincronizado, bem como nos bancos de dados config, admin e local.

      Nota

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

      Database Password

      Insira a senha correspondente à conta do banco de dados.

      Shard account

      Insira a conta do shard da instância de origem do ApsaraDB for MongoDB.

      Nota

      Se a origem for um banco de dados MongoDB autogerenciado, insira também as shard connection information para os nós de shard.

      Shard password

      Insira a senha do shard da instância de origem do ApsaraDB for MongoDB.

      Destination Database

      Select an existing DMS database instance. (Optional. If you have not registered a DMS database instance, ignore this option and configure database settings in the section below.) (Opcional. Se não tiver criado uma conexão, ignore esta opção e configure as informações do banco de dados diretamente na seção abaixo.)

      Selecione uma instância existente conforme necessário.

      • Se usar uma instância existente, as informações do banco de dados serão preenchidas automaticamente. Não é necessário inseri-las novamente.

      • Se não usar uma instância existente, insira as seguintes informações do banco de dados.

      Database Type

      Selecione MongoDB.

      Access Method

      Selecione Alibaba Cloud Instance.

      Instance Region

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

      Architecture

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

      Instance ID

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

      Database Name

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

      Database Account

      Insira a conta do banco de dados da instância de destino do ApsaraDB for MongoDB. Esta conta requer a permissão dbAdminAnyDatabase, permissões de leitura e gravação no banco de dados de destino e permissões de leitura no banco de dados local.

      Database Password

      Insira a senha correspondente à conta do banco de dados.

      Encryption

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

      Nota

      • Bancos de dados MongoDB com Architecture de Sharded Cluster não suportam SSL-encrypted.

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

    3. Na parte inferior da página, clique em Test Connectivity and Proceed.

      Se o banco de dados de origem ou destino for uma instância de banco de dados Alibaba Cloud, como uma instância do ApsaraDB RDS for MySQL ou ApsaraDB for MongoDB, o DTS adiciona automaticamente os blocos CIDR dos servidores DTS à lista de permissões da instância. Se o banco de dados de origem ou destino for um banco de dados autogerenciado hospedado em uma instância do Elastic Compute Service (ecs), o DTS adiciona automaticamente os blocos CIDR dos servidores DTS às regras do grupo de segurança da instância ecs, e você deve garantir que a instância ecs possa acessar o banco de dados. Se o banco de dados de origem ou destino for um banco de dados autogerenciado implantado em um data center ou fornecido por um provedor de service em nuvem terceirizado, adicione manualmente os blocos CIDR dos servidores DTS à lista de permissões do banco de dados para permitir que o DTS acesse o banco de dados. Para mais informações, consulte Whitelist DTS server IP addresses.

      Aviso

      Se os blocos CIDR dos servidores DTS forem adicionados automática ou manualmente à lista de permissões do banco de dados ou instância, ou às regras do grupo de segurança do ecs, podem surgir riscos de segurança. Portanto, antes de usar o DTS para sincronizar dados, entenda e reconheça os riscos potenciais e tome medidas preventivas, incluindo, mas não se limitando a: reforçar a segurança do seu nome de usuário e senha, limitar as portas expostas, autenticar chamadas de API, verificar regularmente a lista de permissões ou regras do grupo de segurança do ecs e proibir blocos CIDR não autorizados, ou conectar o banco de dados ao DTS usando Express Connect, VPN Gateway ou Smart Access Gateway.

    4. Configure os objetos de sincronização e as configurações avançadas.

      Parâmetro

      Descrição

      Synchronization Types

      Incremental Data Synchronization está selecionado. Por padrão, selecione também Schema Synchronization e Full Data Synchronization. Após a conclusão da pré-verificação, o DTS realiza uma sincronização completa de dados dos objetos selecionados da instância de origem para o cluster de destino. Isso serve como dados de base para a subsequente sincronização incremental de dados.

      Synchronization Topology

      Selecione One-way Synchronization.

      Processing Mode of Conflicting Tables

      • Precheck and Report Errors: Verifica se existe uma coleção com o mesmo nome no banco de dados de destino. Se encontrada, um erro é relatado e a tarefa de sincronização de dados não inicia. Caso contrário, a pré-verificação é bem-sucedida.

        Nota

        Se não for possível excluir ou renomear a coleção com o mesmo nome no banco de dados de destino, altere o nome da coleção no banco de dados de destino. Para mais informações, consulte Set the name of a synchronization object in the destination instance.

      • Ignore Errors and Proceed: Ignora a verificação de coleções com o mesmo nome no banco de dados de destino.

        Aviso

        Selecionar Ignore Errors and Proceed pode causar inconsistência de dados e colocar seu negócio em risco. Por exemplo:

        • Se um registro no banco de dados de destino tiver o mesmo valor de chave primária ou chave única que um registro no banco de dados de origem, o registro no banco de dados de destino é mantido. O registro do banco de dados de origem não é sincronizado para o banco de dados de destino.

        • Isso pode causar falha na inicialização de dados, sincronização apenas parcial dos dados ou falha total da sincronização.

      Capitalization of Object Names in Destination Instance

      Configure a política de diferenciação de maiúsculas e minúsculas para nomes de objetos de banco de dados, tabelas e colunas sincronizados na instância de destino. Por padrão, a DTS default policy está selecionada. Também é possível optar por usar as políticas padrão dos bancos de dados de origem e destino. Para mais informações, consulte Case sensitivity policy for destination object names.

      Source Objects

      Na caixa Source Objects, clique em um objeto para sincronizar e, em seguida, clique em 向右 para movê-lo para a caixa Selected Objects.

      Nota

      A sincronização pode ser realizada nos níveis DATABASE e COLLECTION.

      Selected Objects

      • Para renomear um único objeto de sincronização na instância de destino, clique com o botão direito no objeto na caixa Selected Objects. Para mais informações sobre como renomear objetos, consulte Map a single database, table, or column.

      • Para alterar os nomes de vários objetos de sincronização na instância de destino em lote, clique em Batch Edit no canto superior direito da caixa Selected Objects. Para mais informações, consulte Map databases, tables, and columns in a batch.

    5. Clique em Next: Advanced Settings para configurar as definições avançadas.

      • Data Verification Settings

        Para configurar a validação de dados, consulte Configure data validation.

      • Advanced Settings

        Parâmetro

        Descrição

        Dedicated Cluster for Task Scheduling

        Por padrão, o DTS agenda tarefas em um cluster compartilhado, e não é necessário selecionar um cluster. Para um desempenho mais estável, adquira um cluster dedicado para executar tarefas de sincronização do DTS. Para mais informações, consulte What is a DTS dedicated cluster?.

        Retry Time for Failed Connections

        Após o início de uma tarefa de sincronização, se a conexão com o banco de dados de origem ou destino falhar, o DTS relata um erro e inicia imediatamente a tentativa de reconexão. A duração padrão de nova tentativa é de 720 minutos. Especifique uma duração personalizada de 10 a 1.440 minutos. Recomendamos definir a duração para 30 minutos ou mais. Se o DTS se reconectar com sucesso ao banco de dados dentro da duração especificada, a tarefa de sincronização será retomada automaticamente. Caso contrário, a tarefa falhará.

        Nota

        • Se tiver várias instâncias DTS (por exemplo, Instância A e Instância B) que compartilham a mesma origem ou destino, e definir o tempo de nova tentativa de rede para 30 minutos na Instância A e 60 minutos na Instância B, a duração mais curta de 30 minutos será usada para ambas.

        • Como o DTS cobra pelo tempo de execução da tarefa durante o período de nova tentativa de conexão, recomendamos personalizar a duração da nova tentativa com base nas necessidades do seu negócio ou liberar a instância DTS o mais rápido possível após a liberação das instâncias de banco de dados de origem e destino.

        Retry Time for Other Issues

        Após o início da tarefa de sincronização, se ocorrerem outros problemas não relacionados à conectividade com o banco de dados de origem ou destino (como exceções de execução DDL ou DML), o DTS relata um erro e inicia imediatamente operações contínuas de nova tentativa. A duração padrão de nova tentativa é de 10 minutos. Personalize a duração da nova tentativa dentro do intervalo de 1 a 1.440 minutos. Recomendamos definir para 10 minutos ou mais. Se as operações relevantes forem bem-sucedidas dentro da duração de nova tentativa definida, a tarefa de sincronização será retomada automaticamente. Caso contrário, a tarefa falhará.

        Importante

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

        Enable Throttling for Full Data Synchronization

        Durante a fase de sincronização completa, o DTS consome recursos de leitura e gravação dos bancos de dados de origem e destino, o que pode aumentar a carga do banco de dados. Para reduzir a carga nos bancos de dados de origem e destino, defina um limite de taxa para a tarefa de sincronização completa configurando os parâmetros Queries per second (QPS) to the source database, RPS of Full Data Migration e Data migration speed for full migration (MB/s).

        Nota

        • Este item de configuração está disponível apenas quando Synchronization Types está definido como Full Data Synchronization.

        • Também é possível adjust the full synchronization rate após a instância de sincronização estar em execução.

        Enable Throttling for Incremental Data Synchronization

        Defina também um limite de taxa para a tarefa de sincronização incremental. Para aliviar a pressão no banco de dados de destino, configure RPS of Incremental Data Synchronization e Data synchronization speed for incremental synchronization (MB/s).

        Environment Tag

        Selecione uma tag de ambiente para identificar a instância com base nas necessidades do seu negócio. Neste exemplo, não é necessário selecionar uma tag.

        Configure ETL

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

        Monitoring and Alerting

        Especifique se deseja configurar alertas. Se a sincronização falhar ou a latência exceder o limiar especificado, uma notificação será enviada a um contato de alerta.

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

      • Para visualizar os parâmetros da API para configurar esta instância, passe o mouse sobre o botão Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters na dica.

      • Se terminar 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 do trabalho de sincronização, o DTS executa uma pré-verificação. O trabalho só pode começar após todos os itens de pré-verificação serem aprovados.

      • Se a pré-verificação falhar, clique em View Details para o item com falha. Corrija o problema conforme indicado e execute a pré-verificação novamente.

      • Se a pré-verificação retornar um aviso:

        • Se um item de verificação falhar e não puder ser ignorado, clique em View Details ao lado do item. Siga as instruções para corrigir o problema e 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 em sequência para pular o aviso e reexecutar a pré-verificação. Se optar por ocultar o item de aviso, isso pode causar problemas como inconsistência de dados e representar riscos ao seu negócio.

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

    8. Na página Purchase, selecione o método de faturamento e a especificação de link para a instância de sincronização de dados. A tabela a seguir descreve esses parâmetros em detalhes.

      Categoria

      Parâmetro

      Descrição

      New Instance Class

      Billing Method

      • Subscription: Pagamento realizado ao criar a instância. Adequado para necessidades de longo prazo e mais econômico que o pagamento conforme o uso. Quanto maior a duração da assinatura, maior o desconto.

      • Pay-as-you-go: Cobrança horária. Adequado para necessidades de curto prazo. Libere a instância imediatamente após o uso para economizar custos.

      Resource Group Configuration

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

      Link Specification

      O DTS fornece especificações de sincronização com diferentes níveis de desempenho. A especificação do link de sincronização afeta a taxa de sincronização. Escolha uma especificação com base no seu cenário de negócio. Para mais informações, consulte Data synchronization link specifications.

      Subscription Duration

      No modo de assinatura, selecione a duração e a quantidade para a instância de assinatura. Escolha uma assinatura mensal de 1 a 9 meses, ou uma assinatura anual de 1, 2, 3 ou 5 anos.

      Nota

      Esta opção está disponível apenas quando o método de faturamento é Subscription.

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

    10. Clique em Buy and Start. Na caixa de diálogo OK, clique em OK.

      Visualize o progresso da tarefa na página Data Synchronization.