Menu Docs
Página inicial do Docs
/
MongoDB Atlas
/ / / /

espelho mongomiclo

Nesta página

  • Sintaxe
  • Opções
  • Exemplos

Aviso

Quando você usa mongomirror com um filtro de namespace, as transações na origem com namespaces que estão fora do escopo do includeNamespace <database.collection> são consideradas comportamento indefinido e incorrem em possível perda de dados.

mongomirror é uma ferramenta para migrar manualmente dados de um conjunto de réplicas MongoDB existente para um conjunto de réplicas do MongoDB Atlas.

Para executar o mongomirror, você deve especificar:

  • O conjunto de réplicas de origem e o conjunto de réplicas de destino do Atlas.

  • Um usuário no Atlas cluster comprivilégios apropriados , a senha correspondente e privilégios apropriados, se o conjunto de réplicas de origem exigir autenticação.

mongomirror --host <sourceReplSet> \
--destination <atlasCluster> \
--destinationUsername <atlasAdminUser> \
--destinationPassword <atlasPassword> \
[Additional options]

Você pode especificar algumas opções no config file em vez de incluí-las no comando.

--host <host>

As informações do host do conjunto de réplicas de origem. Especifique o nome do conjunto de réplicas e uma lista de sementes dos membros, como a seguir:

<RSname>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>
--username <username>

Se o conjunto de réplicas de origem exigir autenticação, o nome de um usuário no conjunto de réplicas de origem com privilégios para ler qualquer banco de dados, incluindo o banco de dados do local . Um usuário com a função backup fornece os privilégios apropriados. Para obter detalhes sobre os privilégios específicos necessários, consulte Acesso necessário no conjunto de réplicas de origem.

--password <password>

Senha do usuário especificada em --username.

--authenticationDatabase <authenticationDatabase>

O banco de dados no conjunto de réplica de origem onde o usuário especificado no --username foi criado. O banco de dados de autenticação para:

  • Os usuários autenticados por SCRAM são o banco de dados admin .

  • X.509-usuários autenticados são o banco de dados $external.

  • Os usuários autenticados pelo AWS IAM são o banco de dados do $external.

Para saber mais, consulte Banco de dados de autenticação.

--authenticationMechanism <authenticationMechanism>

O mecanismo de autenticação a ser usado para autenticar o usuário no conjunto de réplicas de origem.

Valor
Descrição
RFC 5802 Mecanismo de Autenticação de Resposta de Desafio Salted padrão usando a função de hash SHA-1.
RFC 5802 Mecanismo de Autenticação de Resposta de Desafio Salted padrão usando a função de hash SHA-256.
Autenticação de certificado TLS/SSL do MongoDB.
GSSAPI (Kerberos)
Autenticação externa usando Kerberos. Esse mecanismo está disponível apenas no MongoDB Enterprise.
PLAIN (LDAP SASL)
Autenticação externa usando LDAP. Você também pode utilizar o PLAIN para autenticar usuários do banco de dados. PLAIN transmite senhas em texto simples. Esse mecanismo está disponível apenas no MongoDB Enterprise.
MONGODB-IAM

Novo na versão 0.10.0

Autenticação externa com AWS IAM.

Para autenticar com credenciais AWS IAM, use as seguintes opções:

  • --username <ID da chave de acesso da AWS>

  • --password <secret access key id>

  • --awsSessionToken < Token de sessão AWS >

Para saber mais, consulte Mecanismos de autenticação.

--awsSessionToken

Novo na versão 0.10.0

Um token de sessão da AWS para uso com o mecanismo de autenticação MONGODB-IAM.

--compressors <snappy,...>

Novo na versão 0.9.0

Lista separada por vírgula de compressores para habilitar. Use "nenhum" para desabilitar. Padrão: snappy,zstd,zlib

--config=<file>

Arquivo YAML que armazena opções e valores para mongomirror. Especifique o arquivo utilizando caminhos relativos ou absolutos para executar o mongomirror com as opções que o arquivo contém.

O arquivo de configuração suporta as seguintes opções:

Especifique as opções no arquivo de configuração utilizando a sintaxe do option: value. Não inclua -- antes das opções no arquivo de configuração. Se você definir uma opção no arquivo de configuração, você não precisará especificar esta opção dentro do comando mongomirror.

Exemplo

Crie um arquivo de configuração denominado myconfig.yaml que contenha o seguinte:

password: <passwordForUser>
destinationPassword: <passwordForDestinationUser>

Você pode executar o mongomirror sem incluir as bandeiras --password e --destinationPassword:

mongomirror --host <sourceReplSet> \
--ssl \
--username <atlasAdminUser> \
--destinationUsername <atlasAdminUser> \
--config=myconfig.yaml \
--destination <atlasCluster> \
[Additional options]
--destination <destination>

As informações do host do conjunto de réplicas de destino do Atlas.

Especifique o nome do conjunto de réplicas e uma lista de dados dos membros, como a seguir:

<RSname>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>
--destinationAuthenticationDatabase <authentication database>

Banco de dados de autenticação para o usuário do banco de dados no cluster do Atlas. O banco de dados de autenticação para usuários autenticados do SCRAM é o banco de dados do admin.

Para saber mais, consulte Autenticação de usuário do banco de dados.

--destinationAuthenticationMechanism <authentication mechanism>

Mecanismo de autenticação para o usuário do banco de dados no Atlas cluster. O Atlas oferece as seguintes formas de autenticação para usuários do banco de dados:

Valor
Descrição
RFC 5802 Mecanismo de Autenticação de Resposta de Desafio Salted padrão usando a função de hash SHA-1.
RFC 5802 Mecanismo de Autenticação de Resposta de Desafio Salted padrão usando a função de hash SHA-256.
PLAIN (LDAP SASL)
Autenticação externa usando LDAP. Você também pode utilizar o PLAIN para autenticar usuários do banco de dados. PLAIN transmite senhas em texto simples. Esse mecanismo está disponível apenas no MongoDB Enterprise.

Para saber mais, consulte Autenticação de usuário do banco de dados.

--destinationUsername <Atlas user name>

Nome de um usuário do banco de dados no Atlas cluster com privilégios para ler, escrever e administrar qualquer banco de dados. Um usuário com o role de administrador do Atlas fornece os privilégios apropriados. Para obter detalhes sobre os privilégios específicos necessários, consulte Acesso necessário no cluster de destino.

--destinationPassword <password>

Senha do usuário do banco de dados especificada no --destinationUsername.

--drop

Sinalizador que indica que mongomirror deve descartar todas as coleções de usuários (visíveis em cada banco de dados com listCollections) no cluster de destino. Essa opção não descarta coleções internas como local.system* e o oplog.

--noIndexRestore

Novo na versão 0.10.0

Omitir índices ao migrar dados.

--includeNamespace <database.collection>

Especifique um namespace no cluster de origem para espelhar para o cluster de destino. Pode ser fornecido várias vezes.

Observação

Se uma transação abranger múltiplos namespaces, somente as operações de gravação aplicadas aos namespaces especificados no --includeNamespace ou --includeDB serão aplicadas ao cluster de destino.

--includeDB <database>

Especifique um banco de dados no cluster de origem para espelhar para o cluster de destino. Pode ser fornecida várias vezes.

Observação

Se uma transação abranger múltiplos namespaces, somente as operações de gravação aplicadas aos namespaces especificados no --includeNamespace ou --includeDB serão aplicadas ao cluster de destino.

--ssl

Habilita conexões criptografadas TLS/SSL para o conjunto de réplicas de origem.

--sslPEMKeyFile <file>

O arquivo .pem se o conjunto de réplica de origem exigir que os clientes apresentem um certificado. O arquivo .pem contém o certificado TLS/SSL e a chave. Especifique o arquivo utilizando caminhos relativos ou absolutos.

--sslPEMKeyPassword <value>

Senha para descriptografar o arquivo da chave de certificado especificado no --sslPEMKeyFile. Use se --sslPEMKeyFile estiver criptografado.

--sslCAFile <file>

O arquivo .pem que contém a cadeia de certificados raiz da Autoridade de certificação (CA) para o conjunto de réplicas de origem. Especifique o arquivo utilizando caminhos relativos ou absolutos.

--sslCRLFile <filename>

O arquivo .pem que contém a lista de revogação de certificado para o conjunto de réplica de origem. Especifique o arquivo utilizando caminhos relativos ou absolutos.

--sslAllowInvalidHostnames

Obsoleto. Usar tlsInsecure no lugar.

Desabilita a validação dos certificados TLS/SSL apresentados pelo conjunto de réplicas de origem. Permite que o mongomirror se conecte ao conjunto de réplicas de origem se o nome do host nos certificados não corresponder ao nome do host especificado.

Importante

Esta opção ignora toda a validação do certificado, o que pode resultar na aceitação de certificados inválidos.

--sslAllowInvalidCertificates

Obsoleto. Usar tlsInsecure no lugar.

Ignora as verificações de validação para certificados apresentados pelo conjunto de réplicas de origem. Ao usar a configuração --allowInvalidCertificates, o MongoDB registra como aviso o uso do certificado inválido.

Importante

Esta opção ignora toda a validação do certificado, o que pode resultar na aceitação de certificados inválidos.

--tlsInsecure

Ignora as verificações de validação para a cadeia de certificado do servidor e o nome do host. Isso permite que você use certificados e nomes de host inválidos.

Isso substitui as opções obsoletas sslAllowInvalidHostnames e sslAllowInvalidCertificates .

--gssapiServiceName <name>

Se o conjunto de réplicas de origem utilizar autenticação Kerberos, o nome do serviço utilizando GSSAPI/Kerberos. Só é necessário se o serviço não usar o nome padrão mongodb.

Esta opção está disponível apenas no MongoDB Enterprise.

--gssapiHostName <host>

Se o conjunto de réplica de origem utilizar autenticação Kerberos, o nome de host de um serviço usando GSSAPI/Kerberos. Só é necessário se o nome do host de uma máquina não corresponder ao nome do host resolvido pelo DNS.

Esta opção está disponível apenas no MongoDB Enterprise.

--readPreference <read preference>

Descontinuado desde a versão 0.9.0

mongomirror sempre lê a partir do primário, a menos que a origem seja um único host sem um nome de conjunto de réplicas, caso em que ele faz uma conexão direta somente com esse host.

--writeConcern <write concern>

Obsoleto desde a versão 0.2.3: mongomirror sempre usa a write concern majoritária.

--numParallelCollections <num>, -j <num>

Padrão: 4

O número de coleções para copiar e restaurar em paralelo.

--bypassDocumentValidation

Descontinuado desde a versão 0,2,3: mongomirror sempre ignora a validação do documento.

--bookmarkFile <file>

Padrão: mongomirror.bookmark

Nome do arquivo de marcador de carimbo de data/hora do oplog.

--forceDump

Sinalizador que indica que mongomirror ressincroniza todas as coleções de fontes, mesmo que exista um arquivo de marcador não vazio.

--oplogPath <path>

Novo na versão 0.5.0

Permite que mongomirror armazene em buffer a janela de sincronização inicial do oplog no disco. Quando você especifica um valor para esta opção, o mongomirror transmite as entradas de oplog de origem para o diretório especificado em um único arquivo: <oplogPath>/oplog-mongomirror.bson.sz. Depois que todo o arquivo oplog é reproduzido no cluster de destino, mongomirror remove o arquivo e começa a seguir o oplog de origem sem buffer.

Por padrão, mongomirror transmite entradas de oplog da origem e as aplica ao cluster de destino. No entanto, a migração pode falhar se o oplog de origem não for grande o suficiente para conter toda a sincronização inicial da oplog window. Para evitar esse erro, você pode aumentar o tamanho do oplog de origem ou especificar essa opção para garantir que o oplog de origem não fique sem espaço durante o processo de migração.

Importante

Deve haver espaço em disco suficiente para acomodar todas as entradas de oplog de origem que ocorrem durante a sincronização mongomirror inicial.

Exemplo

Se o oplog de origem for 10 GB e abranger 24 horas de alterações, e a sincronização do mongomirror for estimada em 48 horas, deverá haver pelo menos 20 GB de espaço livre em disco no especificado diretório.

--oplogBatchSize <num>

Padrão: 10.000

Especifique o número de entradas de oplog a serem enviadas em lote. mongomirror permite que um volume de dados com no máximo 16 MB de documentos seja enviado como um lote.

--httpStatusPort <num>

Direciona o mongomirror para iniciar um servidor HTTP na porta especificada. Você pode recuperar o status atual de mongomirror emitindo uma solicitação HTTP GET para http://localhost:<num>.

Ao executar com --httpStatusPort, o mongomirror não sai quando encontra um erro. Em vez disso, registra o erro como normal e relata o erro por HTTP para a porta especificada.

mongomirror retorna um documento em resposta à solicitação HTTP. A sintaxe de exemplo a seguir representa todos os campos de saída possíveis - a resposta real pode retornar apenas um subconjunto desses campos. Consulte a tabela subsequente para obter uma descrição dos campos e quando esperá-los.

{
"stage" : "<stage Name>",
"phase" : "<phase Name>",
"details" : {
"currentTimestamp" : "<BSON timestamp>",
"latestTimestamp" : "<BSON timestamp>",
"lastWriteOnSourceTimestamp" : "<BSON timestamp>",
"<namespace>" : {
"complete" : <boolean>,
"copiedBytes" : <integer>,
"totalBytes" : <integer>,
"createIndexes" : <integer>
},
...
},
"errorMessage" : "<error message>"
}

A tabela a seguir descreve cada campo e seus valores possíveis:

Campo
Descrição
stage

O nome do estágio em andamento. Os valores possíveis são:

  • initializing

    mongomirror começou, mas ainda não está copiando nenhum dado.

  • initial sync

    mongomirror está copiando documentos e índices que já existem na implantação de origem. mongomirror também cauda e aplica entradas do oplog.

  • oplog sync

    mongomirror está seguindo e aplicando entradas do oplog.

phase
O nome da fase. Fornece detalhes mais específicos de qual parte do stage está em andamento.
details

Um documento que fornece uma descrição detalhada do progresso da fase atual.

Durante o estágio initial sync, cada subdocumento em details representa uma única coleção que está sendo copiada por mongomirror.

Dependendo do stage ou phase, mongomirror pode não conter este campo na resposta.

details.<namespace>

O namespace completo da coleção que está sendo copiada, exibido como <database>.<collection>.

Somente é exibido durante a fase initial sync ao copiar documentos ou índices.

details.<namespace>.complete

Exibe true ou false dependendo de o mongomirror ter copiado ou não todos os documentos ou índices da coleção para o cluster do Atlas de destino.

Somente é exibido durante a fase initial sync ao copiar documentos ou índices.

details.<namespace>.copiedBytes

O número de bytes copiados até agora. Observe que essa é uma medida diferente dos logs mongomirror, que informam o número atual/total de documentos copiados.

Exibido somente durante a fase initial sync ao copiar dados que não são de índice.

details.<namespace>.totalBytes

O tamanho total (em bytes) da coleção.

Exibido somente durante a fase initial sync ao copiar dados que não são de índice.

details.<namespace>.createIndexes

O número de índices que foram ou serão criados.

Exibido somente durante o estágio initial sync ao copiar índices.

details.currentTimestamp

O valor do registro de data e hora BSON da entrada do oplog processada mais recentemente. mongomirror só atualiza esse ponto de dados a cada 10 segundos, portanto mongomirror pode estar um pouco mais adiantado em relação ao tempo informado.

Só é exibido durante os estágios initial sync ou oplog sync ao seguir ou aplicar entradas de oplog.

details.latestTimestamp

Durante o estágio initial sync , isso representa o valor do registro de data e hora BSON da última entrada do oplog disponível depois que os dados iniciais foram copiados durante a sincronização inicial.

Durante o estágio oplog sync, isso representa o valor do registro de data e hora BSON da última entrada de oplog disponível no sistema de origem.

Só é exibido durante os estágios initial sync ou oplog sync ao seguir ou aplicar entradas de oplog.

details
.lastWriteOnSourceTimestamp

O valor de carimbo de data/hora BSON da entrada de oplog mais recente que não é um no-op. As entradas não operacionais geralmente são operações no nível do sistema, como pulsações, que não gravam nem editam dados no banco de dados. mongomirror atualiza esse valor a cada 10 segundos. Operações que gravam ou editam dados no banco de dados podem não ser relatadas até que ocorra a próxima atualização.

O campo lastWriteOnSourceTimestamp é útil como confirmação de que nenhuma nova gravação está ocorrendo no sistema de origem antes da interrupção durante a migração.

errorMessage
Uma string que descreve qualquer erro encontrado por mongomirror.
--collStatsThreshold <num>

Novo na versão 0.9.0

Número máximo de coleções que podem existir antes de o collStats ser desabilitado. Utilize -1 para sempre executar collStats ou 0 para nunca executar collStats. Padrão: -1

--removeAutoIndexId

Novidade na versão 0.12.0

Remove a opção autoIndexId das collections durante a initial sync com o cluster de destino. Remove também a opção autoIndexId de qualquer collection que o mongomirror crie durante a migração.

--preserveUUIDs

Permite ao Atlas preservar UUID durante a migração live. Esta opção funciona somente com o processo de migração live que o Atlas executa. Se você utilizar a opção --preserveUUIDs na linha de comando, ela falhará devido a erros de permissão. Esses erros são esperados porque essa opção não se destina a ser usada na linha de comando em um processo de migração autogerenciado que executa mongomirror.

O exemplo a seguir migra de um conjunto de réplicas de origem que não requer autenticação:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017 \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword myAtlasPwd

Para migrar de um conjunto de réplicas de origem que não exige autenticação, execute o mongomirror com as seguintes opções:

Para o destino, especifique o nome do conjunto de réplicas seguido por uma lista de sementes de membros no seguinte formato:

<replicaSetName>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>,...

O usuário especificado deve ter a função Atlas admin no Atlas.

O exemplo a seguir migra um conjunto de réplicas de origem que utiliza autenticação SCRAM-SHA1 para Atlas:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username mySourceUser \
--password mySourcePassword \
--authenticationDatabase admin \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword atlasPassw0Rd

Para migrar de um conjunto de réplicas de origem que utiliza autenticação SCRAM-SHA1, execute o mongomirror com as seguintes opções:

O usuário do conjunto de réplicas de origem deve ter o acesso necessário no cluster de origem. O role do backup fornece os devidos privilégios.

Para o destino, especifique o nome do conjunto de réplicas seguido por uma lista de sementes de membros no seguinte formato:

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

O usuário especificado deve ter o Atlas admin no Atlas.

O exemplo a seguir migra de um conjunto de réplicas de origem que usa autenticação X.509:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry" \
--authenticationDatabase '$external' \
--authenticationMechanism MONGODB-X509 \
--ssl \
--sslPEMKeyFile <path-to-my-client-certificate.pem> \
--sslCAFile <path-to-my-certificate-authority-certificate.pem> \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword atlasPassw0Rd

Para migrar de um conjunto de réplicas de origem que utiliza autenticação X.509, execute o mongomirror com as seguintes opções:

O usuário do conjunto de réplicas de origem deve ter o acesso necessário no cluster de origem. O role do backup fornece os devidos privilégios.

Para o destino, especifique o nome do conjunto de réplicas seguido por uma lista de sementes de membros no seguinte formato:

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

O usuário especificado deve ter o Atlas admin no Atlas.

O exemplo a seguir migra de um conjunto de réplica de origem que usa a autenticação Kerberos:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username sourceUser/administrator@MYREALM.COM \
--authenticationDatabase '$external' \
--authenticationMechanism GSSAPI \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017,atlas-host3:27017 \
--destinationUsername atlasUser \
--destinationPassword atlasPass

Para migrar de um conjunto de réplica de origem que utiliza autenticação Kerberos, execute o mongomirror com as seguintes opções:

O usuário do conjunto de réplicas de origem deve ter o acesso necessário no cluster de origem. O role do backup fornece os devidos privilégios.

Para o destino, especifique o nome do conjunto de réplicas seguido por uma lista de sementes de membros no seguinte formato:

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

O usuário especificado deve ter o Atlas admin no Atlas.

Você pode salvar os registros de saída de um procedimento do mongomirror em um arquivo para exame posterior e depuração. Use o seguinte formato para salvar a saída em um arquivo mongomirror.log :

mongomirror <args> 2>&1 | tee -a mongomirror.log

Voltar

Migrar manualmente

Próximo

mongomirror Changelog