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. Consulte também Baixar o mongomirror.
Sintaxe
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 com privilé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.
Opções
--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çãobackupfornece 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.
--authenticationDatabase <authenticationDatabase>O banco de dados no conjunto de réplica de origem onde o usuário especificado no
--usernamefoi 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.
ValorDescriçãoRFC 5802 mecanismo de autenticação de resposta de desafio salgado padrão usando a função de hash SHA-1.
RFC 5802 mecanismo de autenticação de resposta de desafio salgado 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 somente no MongoDB Enterprise.
PLAIN (LDAP SASL)
Autenticação externa usando LDAP. Você também pode utilizar o
PLAINpara autenticar usuários do banco de dados.PLAINtransmite 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 acessodo Amazon Web Services>--password<secret access key id>--awsSessionToken<AWS session token>
Para saber mais, consulte Mecanismos de autenticação.
--awsSessionTokenNovo 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 omongomirrorcom as opções que o arquivo contém.O arquivo de configuração suporta as seguintes opções:
password<password>sslPEMKeyPassword<password>destinationPassword<password>uri<source cluster URI connection string>
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 comandomongomirror.Exemplo
Crie um arquivo de configuração denominado
myconfig.yamlque contenha o seguinte:password: <passwordForUser> destinationPassword: <passwordForDestinationUser> Você pode executar o
mongomirrorsem incluir as bandeiras--passworde--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:
ValorDescriçãoRFC 5802 mecanismo de autenticação de resposta de desafio salgado padrão usando a função de hash SHA-1.
RFC 5802 mecanismo de autenticação de resposta de desafio salgado padrão usando a função de hash SHA-256.
PLAIN (LDAP SASL)
Autenticação externa usando LDAP. Você também pode utilizar o
PLAINpara autenticar usuários do banco de dados.PLAINtransmite 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.
--dropSinalizador que indica que
mongomirrordeve descartar todas as coleções de usuários (visíveis em cada banco de dados comlistCollections) no cluster de destino. Essa opção não descarta coleções internas comolocal.system*e o oplog.
--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
--includeNamespaceou--includeDBserã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
--includeNamespaceou--includeDBserão aplicadas ao cluster de destino.
--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--sslPEMKeyFileestiver 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.
--sslAllowInvalidHostnamesObsoleto. Usar
tlsInsecureno lugar.Desabilita a validação dos certificados TLS/SSL apresentados pelo conjunto de réplicas de origem. Permite que o
mongomirrorse 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.
--sslAllowInvalidCertificatesObsoleto. Usar
tlsInsecureno 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.
--tlsInsecureIgnora 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
sslAllowInvalidHostnamesesslAllowInvalidCertificates.
--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
mongomirrorsempre 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:
mongomirrorsempre 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.
--bypassDocumentValidationDescontinuado desde a versão 0,2,3:
mongomirrorsempre ignora a validação do documento.
--bookmarkFile <file>Padrão: mongomirror.bookmark
Nome do arquivo de marcador de carimbo de data/hora do oplog.
--forceDumpSinalizador que indica que
mongomirrorressincroniza 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
mongomirrorarmazene em buffer a janela de sincronização inicial do oplog no disco. Quando você especifica um valor para esta opção, omongomirrortransmite 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,mongomirrorremove o arquivo e começa a seguir o oplog de origem sem buffer.Por padrão,
mongomirrortransmite 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
mongomirrorinicial.Por exemplo, se o oplog de origem for 10 GB e abranger 24 horas de alterações, e a sincronização de
mongomirrorfor estimada em 48 horas, deve haver pelo menos 20 GB de espaço livre em disco no diretório especificado.
--oplogBatchSize <num>Padrão: 10.000
Especifique o número de entradas de oplog a serem enviadas em lote.
mongomirrorpermite que um volume de dados com no máximo 16 MB de documentos seja enviado como um lote.
--httpStatusPort <num>Direciona o
mongomirrorpara iniciar um servidor HTTP na porta especificada. Você pode recuperar o status atual demongomirroremitindo uma solicitação HTTPGETparahttp://localhost:<num>.Ao executar com
--httpStatusPort, omongomirrornão sai quando encontra um erro. Em vez disso, registra o erro como normal e relata o erro por HTTP para a porta especificada.mongomirrorretorna 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:
CampoDescriçãostageO nome do estágio em andamento. Os valores possíveis são:
initializingmongomirrorcomeçou, mas ainda não está copiando nenhum dado.initial syncmongomirrorestá copiando documentos e índices que já existem no sistema de origem.mongomirrortambém cauda e aplica entradas do oplog.oplog syncmongomirrorestá seguindo e aplicando entradas do oplog.
phaseO nome da fase. Fornece detalhes mais específicos de qual parte do
stageestá em andamento.detailsUm documento que fornece uma descrição detalhada do progresso da fase atual.
Durante o
initial syncestágio, cada subdocumento emdetailsrepresenta uma única collection que está sendo copiadamongomirrorpor.Dependendo do
stagephaseou, pode não incluir este campo namongomirrorresposta.details.<namespace>O namespace completo da coleção que está sendo copiada, exibido como
<database>.<collection>.Somente é exibido durante a fase
initial syncao copiar documentos ou índices.details.<namespace>.completeExibe
trueou dependendofalsese copioumongomirrorou não todos os documentos ou índices da coleção para o Atlas cluster de destino.Somente é exibido durante a fase
initial syncao copiar documentos ou índices.details.<namespace>.copiedBytesO número de bytes copiados até agora. Observe que essa é uma medida diferente dos registros, que informam
mongomirroro número atual/total de documentos copiados.Exibido somente durante a fase
initial syncao copiar dados que não são de índice.details.<namespace>.totalBytesO tamanho total (em bytes) da coleção.
Exibido somente durante a fase
initial syncao copiar dados que não são de índice.details.<namespace>.createIndexesO número de índices que foram ou serão criados.
Exibido somente durante o estágio
initial syncao copiar índices.details.currentTimestampO valor do registro de data e hora BSON da entrada do oplog processada mais recentemente.
mongomirrorsó atualiza esse ponto de dados a cada 10 segundos, portantomongomirrorpode estar um pouco mais adiantado em relação ao tempo informado.Só é exibido durante os estágios
initial syncouoplog syncao seguir ou aplicar entradas de oplog.details.latestTimestampDurante 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 syncouoplog syncao seguir ou aplicar entradas de oplog.details.lastWriteOnSourceTimestampO valor de carimbo de data/hora BSON da entrada 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.
mongomirroratualiza 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.errorMessageUma string que descreve qualquer erro encontrado
mongomirrorpor.
--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
-1para sempre executar collStats ou0para nunca executar collStats. Padrão:-1
--removeAutoIndexIdNovidade na versão 0.12.0
Remove a opção
autoIndexIddas collections durante a initial sync com o cluster de destino. Remove também a opçãoautoIndexIdde qualquer collection que omongomirrorcrie durante a migração.
--preserveUUIDsPermite 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
--preserveUUIDsna 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 executamongomirror.
Exemplos
Migrar um conjunto de réplica para Atlas: nenhuma autenticação na fonte
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:
--host<sourceReplSet/seed list of members>--destination<Cluster do Atlas>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Migrar um conjunto de réplicas: o conjunto de réplicas de origem utiliza a autenticação SCRAM-SHA1
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:
--host<sourceReplSet/seed list of members>--username<sourceUser>--password<sourcePassword>--authenticationDatabase<sourceDatabase>--destination<Cluster do Atlas>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Migrar um conjunto de réplicas: o conjunto de réplicas de origem requer autenticação do cliente X.509
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:
--host<sourceReplSet/seed list of members>--username<subject from the client certificate>--authenticationMechanismMONGODB-X509--authenticationDatabase'$external'--sslPEMKeyFile<path-to-my-client-certificate.pem>--sslCAFile<path to root CA PEM file>--destination<Cluster do Atlas>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Migrar um conjunto de réplicas: o conjunto de réplicas de origem requer autenticação Kerberos/GSSAPI
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:
--host<sourceReplSet/seed list of members>--username<Kerberos user principal>--authenticationDatabase'$external'--authenticationMechanismGSSAPI--destination<Cluster do Atlas>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Salvar mongomirror a saída em um arquivo
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