Migre o MongoDB para o Oracle AI Database sem tempo de inatividade

Descubra como usar o OCI GoldenGate para MongoDB para o Oracle AI Database sem tempo de inatividade.

O OCI GoldenGate Big Data suporta migrações do MongoDB e do MongoDB Atlas para os seguintes destinos com tempo de inatividade zero:

O Autonomous AI JSON Database e o Autonomous AI Database vêm com a API Oracle pré-configurada para strings de conexão MongoDB que o OCI GoldenGate usa para se conectar aos sistemas Oracle AI Database de destino. Consulte Usando a API do Oracle AI Database para MongoDB para obter mais informações.

Se o seu destino for um Oracle AI Database local, você poderá usar o Oracle Rest Data Services para ativar a API do Oracle AI Database para MongoDB com o seu Oracle AI Database local.

Antes de começar

Para concluir com êxito este início rápido, certifique-se de que:

Configurar e executar a migração

  1. No MongoDB de origem, execute o Utilitário de Dump do MongoDB.

    1. Execute a opção mongodump com --oplog para criar um snapshot do banco de dados MongoDB de origem:

      $ ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v

      O comando retorna o seguinte:

      <date+timestamp>    getting most recent oplog timestamp
      <date+timestamp>    writing admin.system.version to dump/admin/system.version.bson
      <date+timestamp>    done dumping admin.system.version (1 document)
      <date+timestamp>    dumping up to 4 collections in parallel
      <date+timestamp>    writing testDB.coll1 to dump/testDB/coll1.bson
      <date+timestamp>    writing testDB.coll2 to dump/testDB/coll2.bson
      <date+timestamp>    writing testDB.coll3 to dump/testDB/coll3.bson
      <date+timestamp>    done dumping testDB.coll3 (10000 documents)
      <date+timestamp>    done dumping testDB.coll1 (10000 documents)
      <date+timestamp>    done dumping testDB.coll2 (10000 documents)
      <date+timestamp>    writing captured oplog to
      <date+timestamp>    dumped 7 oplog entries

      Isso gera uma pasta de dump contendo o arquivo de dados de arquivamento binário para todos os bancos de dados e coleções no seguinte local:

      dump/database-name/collection-name/collection-name.bson

      Ele também cria uma oplog.bson diretamente na pasta de dump.

    2. Para inspecionar o conteúdo do arquivo oplog.bson (que está em formato binário), você pode convertê-lo em JSON usando o utilitário bsondump:

      $ ./bin/bsondump --pretty --outFile /path/to/oplog.json dump/oplog.bson

      O comando retorna o seguinte:

      <date+timestamp>    7 objects found
  2. Extraia os timestamps da primeira e da última operação de oplong.bson:

    1. Fazer download do script OplogLSN.sh

    2. Execute o script OplongLSN.sh no MongoDB de origem no mesmo diretório onde mongodump está localizado, passando o local para oplog.bson como argumento da seguinte forma:

      $./oplogLSN.sh /path/to/dump/oplog.bson

      O comando retorna o seguinte:

      <date+timestamp> 1 objects found
      First LSN: 1740663867.1
      Last LSN: 1740663946.211
    3. Inspecionar entradas Oplog. Se houver alguma operação de entrada durante o dump, o arquivo oplog.bson conterá entradas para essas operações, cada uma com um timestamp. Você pode usar OplogLSN.sh para capturar os timestamps da primeira e da última operação ou convertê-los em um arquivo JSON para inspeção manual, conforme mostrado na etapa anterior.

  3. Execute o Utilitário de Restauração MongoDB. Use o utilitário mongorestore para restaurar as coleções selecionadas do dump para a instância do MongoDB de destino:

    $ ./mongorestore --uri="mongodb://localhost:27021" --nsInclude=testDB.coll1 --nsInclude=testDB.coll2 /path/to/dump -v

    O comando retorna o seguinte:

    <date+timestamp>    using write concern: &{majority <nil> 0s}
    <date+timestamp>    using default 'dump' directory
    <date+timestamp>    preparing collections to restore from
    <date+timestamp>    found collection admin.system.version bson to restore to admin.system.version
    <date+timestamp>    found collection metadata from admin.system.version to restore to admin.system.version
    <date+timestamp>    don't know what to do with file "dump/oplog.json", skipping...
    <date+timestamp>    found collection testDB.coll1 bson to restore to testDB.coll1
    <date+timestamp>    found collection metadata from testDB.coll1 to restore to testDB.coll1
    <date+timestamp>    found collection testDB.coll2 bson to restore to testDB.coll2
    <date+timestamp>    found collection metadata from testDB.coll2 to restore to testDB.coll2
    <date+timestamp>    reading metadata for testDB.coll1 from dump/testDB/coll1.metadata.json
    <date+timestamp>    reading metadata for testDB.coll2 from dump/testDB/coll2.metadata.json
    <date+timestamp>    creating collection testDB.coll1 with no metadata
    <date+timestamp>    creating collection testDB.coll2 with no metadata
    <date+timestamp>    restoring testDB.coll1 from dump/testDB/coll1.bson
    <date+timestamp>    restoring testDB.coll2 from dump/testDB/coll2.bson
    <date+timestamp>    finished restoring testDB.coll1 (10000 documents, 0 failures)
    <date+timestamp>    finished restoring testDB.coll2 (10000 documents, 0 failures)
    <date+timestamp>    no indexes to restore for collection testDB.coll1
    <date+timestamp>    no indexes to restore for collection testDB.coll2
    <date+timestamp>    20000 document(s) restored successfully. 0 document(s) failed to restore.

    O comando restaura os dados, metadados e definições de índice da coleção especificada para a instância MongoDB/ORDS de destino. Por exemplo, coll1 e coll2 no banco de dados testDB, conforme mostrado na saída acima.

  4. Crie e execute uma Extração de Captura de Dados de Alteração (CDC) em sua implantação de Big Data de origem para MongoDB. Inicie o Extract MongoDB CDC a partir do timestamp da primeira operação (Primeira LSN) obtido na Etapa 2b. Isso garante que a Extração CDC capture operações que ocorrem após o início do processo de dump.

  5. Criar e executar um processo de Replicat do MongoDB.

    1. Use o Arquivo de Trilha CDC gerado na Etapa 4.

    2. Defina oplongReplayLastLsn como o timestamp da última operação (Último LSN) obtido na Etapa 2b, ou o caminho para oplog.bson e o Último LSN será obtido automaticamente. Isso garante que o Replicat seja executado no modo oplong-replay, evitando colisões e garantindo uma inicialização precisa sem perda ou duplicação de dados. Depois que o último timestamp é processado, o Replicat continua no modo normal.

Sugestões

Aqui estão algumas dicas para garantir que sua migração ocorra sem problemas: