Migrar com mongomirror

MongoDB Deployment de Origem

• O MongoDB deployment de origem deve ser um conjunto de réplicas. Se a origem for um MongoDB deployment standalone, antes de executar mongomirror, converta o standalone 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 MongoDB de origem não pode ser um cluster M0 gratuito ou um cluster M2/M5 compartilhado.

• Não altere o sinalizador featureCompatibilityVersion em nenhum momento durante o procedimento.

• Quando você migrar do MongoDB 4.4 ou anterior para um cluster do Atlas que executa o MongoDB 5.0 ou posterior, descarte todos os índices geoHaystack de suas coleções.

• mongomirror não é compatível com índices TTL. Elimine os índices TTL existentes e os reconstrua quando o processo de migração for concluído. Se 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 renameCollection ou executar um pipeline de agregação que inclua o estágio de agregação do $out.

• Você não pode usar o comando renameCollection ou o estágio de agregação $out como parte da initial sync, que é executada como parte do processo mongomirror .

• Você não deve reiniciar o primary durante o estágio initial sync da migração.

• Se a implementação do MongoDB contiver índices com chaves que excedam o Limite de chave de índice, antes de iniciar o procedimento de migração em tempo real, 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, você deverá incluir credenciais de usuário ao executar o mongomirror. Você deve especificar um usuário do banco de dados com, no mínimo, os seguintes privilégios:

• Ler todos os bancos de dados e collections. A role readAnyDatabase no banco de dados admin atende a esse requisito.

• Leia o oplog. Consulte Acesso Oplog.

• Executar 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 de servidor MongoDB têm diferentes roles integradas. Selecione uma role integrada com base na sua versão do servidor MongoDB e execute os comandos apropriados em mongosh:

• Para agrupamentos de origem, um usuário deve ter as funções readAnyDatabase, clusterMonitor e backup.

  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 clusterMonitor e readAnyDatabase. 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 clusterManager e readAnyDatabase, bem como acesso de leitura no banco de dados local. 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 gratuito M0 , M2ou M5 cluster compartilhado.

• Não pode ser uma instância sem servidor.

• 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 mongomirror detectar 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 --drop ou 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 mongomirror está sendo executado, ou

  • Se 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 nslookup a partir da linha de comando. Para saber mais, consulte Os IPs públicos do Atlas cluster mudam?.

Acesso Necessário no Cluster de Destino

mongomirror deve ter acesso de rede ao cluster de destino.

Você deve especificar um usuário do banco de dados com o role Atlas admin para executar o mongomirror. Para saber mais, consulte Adicionar usuários do banco de dados.