Migrer MongoDB vers Oracle AI Database sans temps d'arrêt

Découvrez comment utiliser OCI GoldenGate vers MongoDB vers Oracle AI Database sans temps d'arrêt.

OCI GoldenGate Big Data prend en charge les migrations à partir de MongoDB et de MongoDB Atlas vers les cibles suivantes sans temps d'arrêt :

Autonomous AI JSON Database et Autonomous AI Database sont livrés avec des chaînes de connexion Oracle préconfigurées pour MongoDB qu'OCI GoldenGate utilise pour se connecter aux systèmes Oracle AI Database cible. Pour plus d'informations, reportez-vous à Utilisation de l'API Oracle AI Database pour MongoDB.

Si votre cible est une base de données Oracle AI Database sur site, vous pouvez utiliser Oracle Rest Data Services pour activer l'API Oracle AI Database pour MongoDB avec votre base de données Oracle AI Database sur site.

Avant de commencer

Pour terminer ce démarrage rapide, assurez-vous de disposer des éléments suivants :

Configurer et exécuter la migration

  1. Dans votre MongoDB source, exécutez l'utilitaire de vidage MongoDB.

    1. Exécutez mongodump avec l'option --oplog pour créer un cliché de la base de données MongoDB source :

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

      La commande renvoie les éléments suivants :

      <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

      Cela génère un dossier de vidage contenant le fichier de données d'archive binaire pour toutes les bases de données et collections à l'emplacement suivant :

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

      Elle crée également un fichier oplog.bson directement sous le dossier de vidage.

    2. Pour inspecter le contenu du fichier oplog.bson (au format binaire), vous pouvez le convertir en JSON à l'aide de l'utilitaire bsondump :

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

      La commande renvoie les éléments suivants :

      <date+timestamp>    7 objects found

  2. Extraire les horodatages de la première et de la dernière opération à partir de oplong.bson :

    1. Télécharger le script OplogLSN.sh

    2. Exécutez le script OplongLSN.sh dans votre MongoDB source dans le même répertoire que mongodump, en transmettant l'emplacement à oplog.bson en tant qu'argument comme suit :

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

      La commande renvoie les éléments suivants :

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

    3. Inspectez les entrées Oplog. S'il y avait des opérations entrantes pendant le vidage, le fichier oplog.bson contient des entrées pour ces opérations, chacune avec un horodatage. Vous pouvez utiliser OplogLSN.sh pour capturer les horodatages de la première et de la dernière opération ou le convertir en fichier JSON pour inspection manuelle, comme indiqué à l'étape précédente.

  3. Exécutez l'utilitaire de restauration MongoDB. Utilisez l'utilitaire mongorestore pour restaurer les collections sélectionnées à partir du fichier dump vers l'instance MongoDB cible :

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

    La commande renvoie les éléments suivants :

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

    La commande restaure les définitions de données, de métadonnées et d'index de la collection indiquée vers l'instance MongoDB/ORDS cible. Par exemple, coll1 et coll2 dans la base de données testDB, comme indiqué dans la sortie ci-dessus.

  4. Créer et exécuter une extraction de capture de données de modification (CDC) sur le déploiement Big Data source pour MongoDB. Démarrez l'extraction CDC MongoDB à partir de l'horodatage de la première opération (premier LSN) obtenu à l'étape 2b. Cela garantit que l'extraction CDC capture les opérations qui se produisent après le démarrage du processus de vidage.

  5. Créer et exécuter une réplication MongoDB.

    1. Utilisez le fichier de trace CDC généré à l'étape 4.

    2. Définissez oplongReplayLastLsn sur l'horodatage de la dernière opération (dernier LSN) obtenu à l'étape 2b, ou sur le chemin oplog.bson et le dernier LSN est obtenu automatiquement. Ainsi, le processus Replicat s'exécute en mode oplong-replay, ce qui évite les collisions et garantit un lancement précis sans perte de données ni duplication. Une fois le dernier horodatage traité, le processus Replicat continue en mode normal.

Astuces

Voici quelques conseils pour garantir le bon déroulement de votre migration :