espelho mongomiclo
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.
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 cluster do Atlas 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çãobackup
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.
--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.
ValorDescriçãoRFC 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 somente 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 acessodo Amazon Web Services>--password
<secret access key id>--awsSessionToken
<AWS session token>
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 omongomirror
com 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.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:
ValorDescriçãoRFC 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 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
--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.
--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
esslAllowInvalidCertificates
.
--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, omongomirror
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.Por exemplo, se o oplog de origem for 10 GB e abranger 24 horas de alterações, e a sincronização de
mongomirror
for 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.
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 demongomirror
emitindo uma solicitação HTTPGET
parahttp://localhost:<num>
.Ao executar com
--httpStatusPort
, omongomirror
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:
CampoDescriçãostage
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 no sistema 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
initial sync
estágio, cada subdocumento emdetails
representa uma única collection que está sendo copiadamongomirror
por.Dependendo do
stage
ouphase
, pode não incluir este campo namongomirror
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 dependendofalse
se copioumongomirror
ou não todos os documentos ou índices da coleção para o Atlas cluster 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 registros, que informam
mongomirror
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, portantomongomirror
pode estar um pouco mais adiantado em relação ao tempo informado.Só é exibido durante os estágios
initial sync
ouoplog 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
ouoplog sync
ao seguir ou aplicar entradas de oplog.details
.lastWriteOnSourceTimestamp
O 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 banco de dados. atualiza esse valor a
mongomirror
cada 10 segundos. Operações que gravam ou editam dados no banco de 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
mongomirror
por.
--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 ou0
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çãoautoIndexId
de qualquer collection que omongomirror
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 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>--authenticationMechanism
MONGODB-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'
--authenticationMechanism
GSSAPI
--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