Esegui la migrazione di MongoDB a Oracle AI Database senza tempi di inattività

Scopri come utilizzare OCI GoldenGate per MongoDB in Oracle AI Database senza tempi di inattività.

OCI GoldenGate Big Data supporta le migrazioni da MongoDB e MongoDB Atlas alle destinazioni seguenti senza tempi di inattività:

Autonomous AI JSON Database e Autonomous AI Database sono dotati di Oracle API preconfigurata per le stringhe di connessione MongoDB utilizzate da OCI GoldenGate per connettersi AI sistemi Oracle AI Database di destinazione. Per ulteriori informazioni, vedere Using Oracle AI Database API for MongoDB.

Se la tua destinazione è un Oracle AI Database on-premise, puoi utilizzare i servizi di dati Oracle Rest per abilitare Oracle AI Database API for MongoDB con Oracle AI Database on-premise.

Prima di iniziare

Per completare correttamente questo avvio rapido, assicurarsi di avere:

Impostare ed eseguire la migrazione

  1. In MongoDB di origine, eseguire MongoDB Dump Utility.

    1. Eseguire mongodump con l'opzione --oplog per creare uno snapshot del database MongoDB di origine:

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

      Il comando restituisce quanto segue:

      <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

      Questa operazione genera una cartella di dump contenente il file di dati dell'archivio binario per tutti i database e le raccolte nella seguente posizione:

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

      Crea anche un oplog.bson direttamente nella cartella di dump.

    2. Per ispezionare il contenuto del file oplog.bson (che è in formato binario), è possibile convertirlo in JSON utilizzando l'utilità bsondump:

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

      Il comando restituisce quanto segue:

      <date+timestamp>    7 objects found

  2. Estrai gli indicatori orari della prima e dell'ultima operazione da oplong.bson:

    1. Scarica lo script OplogLSN.sh

    2. Eseguire lo script OplongLSN.sh nel MongoDB di origine nella stessa directory in cui si trova mongodump, passando la posizione a oplog.bson come argomento come indicato di seguito.

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

      Il comando restituisce quanto segue:

      <date+timestamp> 1 objects found
First LSN: 1740663867.1
Last LSN: 1740663946.211

    3. Ispezionare le voci Oplog. Se durante il dump sono state eseguite operazioni in entrata, il file oplog.bson contiene le voci per tali operazioni, ognuna con un indicatore orario. È possibile utilizzare OplogLSN.sh per acquisire gli indicatori orari della prima e dell'ultima operazione o convertirli in un file JSON per l'ispezione manuale, come mostrato nel passo precedente.

  3. Eseguire la utility di ripristino MongoDB. Utilizzare la utility mongorestore per ripristinare le raccolte selezionate dal dump all'istanza MongoDB di destinazione:

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

    Il comando restituisce quanto segue:

    <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.

    Il comando ripristina le definizioni di dati, metadati e indice per la raccolta specificata nell'istanza MongoDB/ORDS di destinazione. Ad esempio, coll1 e coll2 in database testDB come mostrato nell'output precedente.

  4. Creare ed eseguire un'estrazione CDC (Change Data Capture) nella distribuzione Big Data di origine per MongoDB. Avviare l'estrazione CDC MongoDB dal primo indicatore orario dell'operazione (primo LSN) ottenuto nel passo 2b. Ciò garantisce che CDC Extract acquisisca le operazioni che si verificano dopo l'avvio del processo di dump.

  5. Creare ed eseguire una replica MongoDB.

    1. Utilizzare il file trail CDC generato dal passo 4.

    2. Impostare oplongReplayLastLsn sull'indicatore orario dell'ultima operazione (Ultima LSN) ottenuto al passo 2b oppure il percorso a oplog.bson e l'ultimo LSN viene ottenuto automaticamente. Ciò garantisce che Replicat venga eseguito in modalità oplong-replay, evitando collisioni e garantendo un avvio preciso senza perdita o duplicazione di dati. Dopo l'elaborazione dell'ultimo indicatore orario, Replicat continua in modalità normale.

Suggerimenti

Ecco alcuni suggerimenti per garantire che la migrazione vada senza problemi: