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

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

Le service de mégadonnées pour OCI GoldenGate prend en charge les migrations depuis MongoDB et MongoDB Atlas vers les cibles suivantes sans temps d'arrêt :

  • Oracle Autonomous AI JSON Database
  • Oracle Autonomous AI Database
  • Base de données Oracle optimisée par l'IA

Les chaînes de connexion Autonomous AI JSON Database et Autonomous AI Database sont fournies avec l'API Oracle pour MongoDB préconfigurée utilisée par OCI GoldenGate pour se connecter aux systèmes Oracle AI Database cibles. Pour plus d'informations, voir Utilisation de l'API Oracle Database API for MongoDB.

Si votre cible est Oracle AI Database sur place, vous pouvez utiliser les services Oracle Rest Data Services pour activer l'API Oracle Database API for MongoDB avec votre Oracle AI Database sur place.

Avant de commencer

Pour réussir ce démarrage rapide, assurez-vous d'avoir :

  • Une source MongoDB, version 5 ou supérieure
  • A créé un déploiement du service de mégadonnées pour OCI GoldenGate, version 23.7 ou supérieure
  • MongoDB Outils de base de données, notamment mongodump et mongostore, installés et chemins de répertoire respectifs ajoutés à la variable d'environnement PATH

Configurer et exécuter la migration

  1. Dans votre source MongoDB, exécutez l'utilitaire de vidage MongoDB.
    1. Exécutez mongodump avec l'option --oplog pour créer un instantané de la base de données source MongoDB :
      $ ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v

      La commande retourne 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
      Il 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 retourne 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 source MongoDB 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 retourne 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 a eu 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 saisir les horodatages de la première et de la dernière opération ou les convertir en fichier JSON à des fins d'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 vidage vers l'instance MongoDB cible :
    $ ./mongorestore --uri="mongodb://localhost:27021" --nsInclude=testDB.coll1 --nsInclude=testDB.coll2 /path/to/dump -v

    La commande retourne 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 données, les métadonnées et les définitions d'index pour la collection spécifiée dans 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éez et exécutez une extraction de saisie de modification de données (CDC) sur votre déploiement du service de mégadonnées 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. Ainsi, l'extraction CDC saisit les opérations qui se produisent après le démarrage du processus de vidage.
  5. Créez et exécutez une réplication MongoDB.
    1. Utilisez le fichier de piste CDC généré à l'étape 4.
    2. Réglez oplongReplayLastLsn à l'horodatage de la dernière opération (dernier LSN) obtenu à l'étape 2b, ou le chemin d'accès à oplog.bson et au dernier LSN est obtenu automatiquement. Cela garantit que le processus Replicat s'exécute en mode oplong-replay, évitant les collisions et garantissant un lancement précis sans perte de données ni duplication. Une fois le dernier horodatage traité, le processus Replicat se poursuit en mode normal.

Conseils

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

  • Il est recommandé d'utiliser mongodb-database-tools version 100.10.0 ou inférieure.
  • Avant d'exécuter mongodump, nettoyez le dossier de vidage existant pour supprimer les données incohérentes.
  • Restauration MongoDB : Plusieurs collections d'une base de données peuvent être répliquées à l'aide de plusieurs options --nsInclude dans la commande mongorestore. Toutefois, les bases de données multiples ORDS ne peuvent pas être restaurées à l'aide de plusieurs commandes --nsInclude. Vous devez utiliser plusieurs commandes de restauration, une pour chaque base de données à restaurer.