mongomirror é uma ferramenta de migração manualmente de dados de um conjunto de réplicas existente do MongoDB para um conjunto de réplicas do MongoDB Atlas. Consulte Baixar o mongomirror.
mongomirror não exige que você encerre seu conjunto de réplicas ou aplicativos existentes, não importa dados de usuário ou função, e não copia o banco de dados config.
Use mongomirror para:
Executando uma migração única de um conjunto de dados para um cluster Atlas do MongoDB a partir de uma implantação do MongoDB hospedada fora do MongoDB Atlas.
Executando uma migração única de um conjunto de dados de um Atlas cluster para outro Atlas cluster.
Consulte também Escolhendo uma Ferramenta de Importação e Migração de Dados.
Pré-requisitos
MongoDB Deployment de Origem
O deployment de origem do MongoDB deve ser um conjunto de réplicas. Se a origem for uma implantação autônoma do MongoDB, antes de executar
mongomirror, converta a autônoma em um conjunto de réplicas.O conjunto de réplicas de origem deve executar MongoDB versão 2.6 ou superior.
O conjunto de réplicas do MongoDB de origem não pode ser um cluster
M0grátis ou um cluster Flex.O conjunto de réplicas de origem do MongoDB não pode conter dados em coleções de séries temporais.
Não altere o sinalizador
featureCompatibilityVersionem nenhum momento durante o procedimento.Quando você migrar do MongoDB 4.4 ou anterior para um cluster do Atlas que executa o MongoDB 7.0 ou posterior, descarte todos os índices geoHaystack de suas coleções.
mongomirrornão é compatível com índices TTL. Elimine os índices TTL existentes e os reconstrua quando o processo de migração for concluído. Se você não quiser eliminar um índice existente por ele ser importante para o desempenho da query, entre em contato com o suporte para obter opções alternativas.Não faça nenhuma alteração de namespace durante o processo de migração, por exemplo, utilizar o comando
renameCollectionou executar um pipeline de agregação que inclua o estágio de agregação do$out.Você não pode usar o comando
renameCollectionou o estágio de agregação$outcomo parte da sincronização inicial, que é executada como parte do processomongomirror.Não reinicie o primário durante o estágio de sincronização inicial da migração.
Se a implantação do MongoDB contiver índices com chaves que excedam o Limite de chave de índice, antes de iniciar o procedimento de migração em produção, modifique os índices para que eles não contenham chaves de tamanho grande.
Acesso necessário no conjunto de réplicas de origem
O mongomirror deve ter acesso de rede ao conjunto de réplicas de origem. Se o conjunto de réplicas de origem exigir autenticação, inclua as credenciais de usuário ao executar mongomirror. Especifique um usuário de banco de dados com, no mínimo, os seguintes privilégios:
Ler todos os bancos de dados e coleções. A função
readAnyDatabaseno banco de dadosadminatende a esse requisito.Leia o oplog. Consulte Acesso Oplog.
Execute o comando
getParameter.
Se um usuário assim não existir, crie o usuário em seu conjunto de réplicas MongoDB de origem. Diferentes versões do MongoDB Server têm diferentes roles integradas. Selecione uma role integrada com base na sua versão do MongoDB Server e execute os comandos apropriados mongosh em:
Para agrupamentos de origem, um usuário deve ter as funções
readAnyDatabase,clusterMonitorebackup.Para verificar se o usuário do banco de dados que executará o processo de migração em produção tem essas funções, execute o comando db.getUser() no banco de dados
admin.use admin db.getUser("admin") { "_id" : "admin.admin", "user" : "admin", "db" : "admin", "roles" : [ { "role" : "backup", "db" : "admin" }, { "role" : "clusterMonitor", "db" : "admin" } { "role" : "readAnyDatabase", "db" : "admin" } ] } ... Além disso, o usuário do banco de dados do cluster de origem deve ter a função de ler o oplog no banco de dados
admin. Para saber mais, consulte Oplog Access.Nos clusters de origem que executam o MongoDB 3.4, o usuário deve ter, no mínimo, as funções
clusterMonitorereadAnyDatabase. Por exemplo:use admin db.createUser( { user: "mySourceUser", pwd: "mySourceP@$$word", roles: [ "clusterMonitor", "readAnyDatabase" ] } ) Em clusters de origem que executam o MongoDB 3.2, um usuário deve ter, no mínimo, ambas as funções de
clusterManagerereadAnyDatabase, bem como acesso de leitura no banco de dadoslocal. Isso requer uma função personalizada, que você pode criar com os seguintes comandos:use admin db.createRole( { role: "migrate", privileges: [ { resource: { db: "local", collection: "" }, actions: [ "find" ] } ], roles: ["readAnyDatabase", "clusterManager"] } ) db.createUser( { user: "mySourceUser", pwd: "mySourceP@$$word", roles: [ "migrate" ] } ) Para clusters de origem que executam o MongoDB 2.6 ou 3.0, o usuário deve ter, no mínimo, a função
readAnyDatabase. Por exemplo:use admin db.createUser( { user: "mySourceUser", pwd: "mySourceP@$$word", roles: [ "readAnyDatabase" ] } )
Implementação do Sistema Atlas
O sistema do Atlas de destino:
Não pode ser um cluster
M0grátis ou um cluster Flex.Não pode ser uma instância sem servidor (descontinuado).
Deve ser um conjunto de réplicas.
Deve ter a versão que é igual ou posterior à versão MongoDB do cluster de origem. Consulte Caminho de atualização.
Não deve conter nenhum namespace que se sobreponha ao cluster de origem. Se o
mongomirrordetectar sobreposição de namespaces no cluster de destino, ocorrerá uma falha antes de iniciar o processo. Se o cluster de destino tiver namespaces sobrepostos, exclua todos os dados do cluster de destino com--dropou liste os namespaces a serem importados do cluster de origem com--includeNamespace.Deve incluir na sua lista de acesso IP:
O endereço IP público do servidor no qual o
mongomirrorestá sendo executado, ouSe configurado para emparelhamento da VPC, o bloco CIDR da VPC do peer (ou um subconjunto) ou o Grupo de Segurança do peer VPC.
Observação
Para localizar o endereço IP público para qualquer nó em seu cluster, utilize a ferramenta
nslookupa partir da linha de comando. Para saber mais, consulte Os IPs públicos dos clusters do Atlas mudam?.
Acesso Necessário no Cluster de Destino
mongomirror deve ter acesso de rede ao cluster de destino.
Você deve especificar um usuário de banco de dados com o Atlas admin role para executar mongomirror o. Para saber mais, consulte.
Caminho de atualização
Importante
mongomirror não é suportado para migrações entre MongoDB 6.0+ clusters de origem e 6.0+ clusters de destino. Você não pode usar para migrar de um conjunto de mongomirror réplicas 6 de0 origem..x ou posterior para um conjunto de réplicas de destino 6.0.x ou mais tarde.
Você pode usar para migrar de um conjunto de réplicas de origem em versões anteriores para um conjunto de réplicas de destino com o mongomirror MongoDB 6.0 versão.
Como alternativa, você pode fazer upgrade de seu conjunto de réplicas de origem para 6.0+ ou 7.0+ e usar este procedimento de migração em produção para migrar um conjunto de réplicas atualizado para o Atlas.
mongomirror permite os seguintes caminhos de migração.
Source Replica Set MongoDB Version | Target Atlas Replica Set MongoDB Version |
|---|---|
5.0 | 6.0 |
4.4 | 6.0 |
4.2 | 6.0 |
4.0 | 6.0 |
3.6 | 6.0 |
3.4 | 6.0 |
3.2 | 6.0 |
3.0 | 6.0 |
2.6 | 6.0 |
Download mongomirror
Observação
No macOS 64-bit, um alerta de segurança aparece quando você tenta abrir o arquivo mongomirror pela primeira vez depois de baixá-lo. Para continuar, consulte Abrir um aplicativo substituindo as configurações de segurança.
Sistema operacional | Download |
|---|---|
Amazon Linux 1 | |
Amazon Linux 2 | |
Debian 9.2 | |
Debian 10 | |
macOS 64-bit | |
RHEL 7.0 | |
RHEL 7.1 PPC64LE | |
RHEL 7,2 s390x | |
RHEL 8.0 | |
RHEL 8.1 PPC64LE | |
SLES 12 | |
SLES 15 | |
Ubuntu 16.04 | |
Ubuntu 16.04 BRAÇO | |
Ubuntu 18.04 | |
Ubuntu 18.04 BRAÇO | |
Ubuntu 20.04 | |
Ubuntu 20.04 BRAÇO | |
Windows |
mongomirror Processo
Quando você inicia o mongomirror, ele:
Conecta-se ao Atlas por TLS/SSL.
Executa uma sincronização inicial, copiando collections do conjunto de réplicas MongoDB existente definido para o cluster de destino no Atlas.
Após a sincronização inicial, executa continuamente o oplog do conjunto de réplicas para alterações de entrada e as reproduz no cluster de destino no Atlas.
mongomirrornão copia oconfigbanco de dados do.mongomirrorO usa compactação de fio se você habilitá-lo no cluster de origem ou de destino e usar--compressorspara especificar quais bibliotecas de compactação permitir.mongomirrorcria todos os índices no cluster de destino em primeiro plano, independentemente de como os índices foram criados no cluster de origem. As compilações de índice em primeiro plano bloqueiam todas as outras operações no banco de dados. Para saber mais, consulte Operações de Compilação de Índice em uma Coleção Preenchida.
Uma vez iniciado, o mongomirror é executado continuamente até você desligá-lo:
Se você desligar o
mongomirrordurante o estágio initial sync, antes de reiniciar omongomirror, verifique se o cluster de destino está vazio ou execute omongomirrorcom--drop.Se você desligar
mongomirrordurante o estágio de acompanhamento do oplog, o processo deixará de acompanhar o oplog. Você pode reiniciarmongomirrorpara continuar acessando o último registro de log processado usando--bookmarkFile.
EXECUTAR mongomirror
Configure o usuário do banco de dados no conjunto de réplicas de origem.
Se o conjunto de réplica de origem exigir autenticação, você deverá incluir credenciais de usuário ao executar o mongomirror. Para saber os requisitos, consulte Acesso necessário no conjunto de réplicas de origem.
Anote o nome de usuário e senha desse usuário, pois você deve especificar essas credenciais ao executar o mongomirror.
No Atlas, VáGo para a Database & Network Access página do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione seu projeto no menu Projects na barra de navegação.
Na barra lateral, clique em Database & Network Access sob o título Security.
A página Acesso ao banco de dados e à rede é exibida.
Configure um usuário de banco de dados no Atlas cluster de destino.
Você deve especificar um usuário de banco de dados com o Atlas admin role para mongomirror executar o. Consulte para obter a documentação sobre a criação de um usuário de banco de dados.
Se esse usuário não existir, crie o usuário:
Se ainda não estiver sendo exibido, clique na aba Database Users.
Clique em Add New Database User.
Adicione um usuário Atlas admin .
Anote o nome de usuário e senha selecionados para o novo usuário, pois você deve especificar estas credenciais ao executar o mongomirror.
Atualizar Lista de Acesso IP.
Se o host onde você executará o mongomirror não estiver na Lista de Acesso IP do seu cluster, atualize a lista. Você pode especificar:
O endereço IP público do servidor no qual o
mongomirrorserá executado, ouSe configurado para emparelhamento da VPC, o bloco CIDR da VPC do par (ou uma sub-rede) ou o grupo de segurança da VPC do mesmo par.
No Atlas, váGo para a Clusters página do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Copie as informações do host cluster de destino.
Você pode obter informações de nome de host do seu agrupamento do Atlas a partir da interface de usuário do Atlas.
Observação
Você não precisa usar um driver para migrar dados com mongomirror.
Na caixa de diálogo Connect, clique em Shell.
Na lista suspensa, selecione 3.4 or earlier. A cadeia de conexão deve ser semelhante ao exemplo a seguir. Este exemplo foi dividido em várias linhas para legibilidade:
mongodb://<db_username>:<db_password>@ 00.foo.mongodb.net:27017, 01.foo.mongodb.net:27017, 02.foo.mongodb.net:27017/test? ssl=true&replicaSet=myAtlasRS&authSource=admin Em um editor de texto, cole o valor de
replicaSet, adicione uma barra (/) e acrescente a lista de hospedagem como valores separados por vírgula, conforme mostrado no exemplo a seguir:myAtlasRS/00.foo.mongodb.net:27017,01.foo.mongodb.net:27017,02.foo.mongodb.net:27017
Use esse valor para --destination na próxima etapa.
Para concluir o processo de migração, verifique a transferência de dados e alterne para o Atlas.
Mudar para Atlas
Depois que mongomirror concluir a initial sync e fizer o tails do oplog do conjunto de réplicas, você poderá alternar para o Atlas cluster de destino.
Verifique a transferência de dados.
Verifique se seus dados foram transferidos para o cluster de destino utilizando uma das seguintes estratégias de verificação. Utilize os seguintes métodos de verificação apenas após garantir que os clusters de origem ou destino NÃO estejam gravando dados.
Use o método db.collection.countDocuments() método em cada coleção nos clusters de origem e de destino para obter contagens de documentos e compará-las entre os clusters.
Grave um script que faça queries nas coleções do cluster de origem e, em seguida, verifique se os documentos, índices, coleções, metadados e visualizações corretos existem com os mesmos valores no cluster de destino. No script, utilize os seguintes comandos nos clusters de origem e destino:
Para verificar a transferência de índices e comparar os resultados, utilize o db.coleção.getIndexes() .
Para verificar a transferência de metadados e comparar os resultados, use o método db.getCollectionInfos().
Atualize aplicativos do cliente para usar o Atlas cluster.
Atualize seus aplicativos cliente com a cadeia de conexão Atlas fornecida por meio do botão Connect no painel do cluster.
Para obter detalhes sobre conexões com o Atlas, consulte Conectar-se a um cluster via drivers.
Monitoramento
mongomirror registra seu progresso na saída padrão do terminal. Durante o initial sync, o mongomirror registra uma barra de progresso para cada collection copiada. Por exemplo:
2024-08-09T16:35:50.227-0000 [#....................] park.events 2179/34184 (6.4%) 2024-08-09T16:35:50.227-0000 [#############........] zoo.animals 29000/49778 (58.3%)
Ao finalizar o oplog, o mongomirror registra o tempo de atraso, em segundos, entre a entrada de oplog mais recente no cluster de origem e a última entrada de oplog processada no cluster de destino. Por exemplo:
2024-12-12T16:22:17.027-0800 Current lag from source: 6s
Um tempo de atraso de 6 segundos significa que a última entrada do oplog mongomirror processada ocorreu 6 segundos antes da entrada mais recente disponível no cluster de origem.
Observação
O tempo necessário para que mongomirror se atualize pode ser maior ou menor que 6 segundos, dependendo do número de entradas que chegam por segundo.
Um tempo de atraso de 0 segundos indica que mongomirror está processando entradas que chegaram menos de um segundo antes da última entrada do oplog.
Se o cluster de origem tiver índices, o mongomirror construirá os mesmos índices no cluster de destino. O registro de progresso mostra os horários de início e fim do processo de construção do índice. Para visualizar o progresso das construções do índice, você pode:
Use o comando currentOp no nó primário do cluster de destino. O campo
commandmostra informações sobre a operação em execução. As entradas de construção de índice são semelhantes a estas:"command" : { "createIndexes" : "perfs", "indexes" : [ { "key" : { "animal" : "text" }, "name" : "animal_text" } ]... Baixar os registros do mongodb para seu cluster de destino e procurar entradas recentes para linhas relacionadas ao índice. As mensagens de log relacionadas à construção de índices são semelhantes a estas:
{"t":{"$date":"2024-08-09T16:35:50.227+00:00"},"s":"I", "c":"INDEX", "id":20447, "ctx":"conn1080","msg":"Index build: completed","attr":{"buildUUID":{"uuid":{"$uuid":"c4a62739-bf19-456d-bbd6-7baa29f1063b"}}}}
Desempenho
Para evitar a contenção de recursos de rede e CPU, execute mongomirror em hosts diferentes dos hosts de instância mongod do conjunto de réplicas.
mongomirrorafeta o desempenho do seu conjunto de réplica de origem, semelhante ao ter um secundário:Para o estágio initial sync, a carga é escalonada de acordo com o tamanho do seu conjunto de dados.
Após a conclusão de um initial sync, a carga é dimensionada com gigabytes do oplog usado por hora.
Sintaxe de Comando, Opções e Exemplos
Para obter a sintaxe, as opções e os exemplos do mongomirror, consulte a página de referência do mongomirror.