Migre MongoDB a Oracle Database sin tiempo de inactividad

Descubra cómo utilizar OCI GoldenGate para MongoDB en Oracle Database sin tiempo de inactividad.

OCI GoldenGate Big Data soporta migraciones desde MongoDB y MongoDB Atlas a Oracle Autonomous JSON Database, Oracle Autonomous Database y Oracle Database sin tiempo de inactividad. Autonomous JSON Database y Oracle Autonomous Database incluyen cadenas de conexión de API de Oracle para MongoDB preconfiguradas que OCI GoldenGate utiliza para conectarse a los sistemas de Oracle Database de destino. Consulte Uso de Oracle Database API for MongoDB para obtener más información. Si su destino es una instancia de Oracle Database local, puede utilizar Oracle Rest Data Services para activar la API de Oracle Database API for MongoDB con su instancia de Oracle Database local.

Antes de empezar

Para completar correctamente este inicio rápido, asegúrese de tener:

  • Un origen MongoDB, versión 5 o superior
  • Se ha creado un despliegue de OCI GoldenGate Big Data, versión 23.7 o superior
  • Herramientas de base de datos MongoDB, incluidas mongodump y mongostore, instaladas y rutas de directorio respectivas agregadas a la variable de entorno PATH

Configurar y ejecutar la migración

  1. En el origen MongoDB, ejecute la utilidad de volcado MongoDB.
    1. Ejecute mongodump con la opción --oplog para crear una instantánea de la base de datos MongoDB de origen:
      $ ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v

      El comando devuelve lo siguiente:

      <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
      Esto genera una carpeta de volcado que contiene el archivo de datos de archivo binario para todas las bases de datos y recopilaciones en la siguiente ubicación:
      dump/database-name/collection-name/collection-name.bson
      También crea un archivo oplog.bson directamente en la carpeta de volcado.
    2. Para inspeccionar el contenido del archivo oplog.bson (que está en formato binario), puede convertirlo a JSON mediante la utilidad bsondump:
      $ ./bin/bsondump --pretty --outFile /path/to/oplog.json dump/oplog.bson

      El comando devuelve lo siguiente:

      <date+timestamp>    7 objects found
  2. Extraiga los registros de hora de la primera y última operación de oplong.bson:
    1. Descargue el script OplogLSN.sh
    2. Ejecute el script OplongLSN.sh en el origen MongoDB en el mismo directorio donde se encuentra mongodump, transfiriendo la ubicación a oplog.bson como argumento de la siguiente manera:
      $./oplogLSN.sh /path/to/dump/oplog.bson

      El comando devuelve lo siguiente:

      <date+timestamp> 1 objects found
      First LSN: 1740663867.1
      Last LSN: 1740663946.211
    3. Inspeccionar entradas de Oplog. Si hubiera alguna operación entrante durante el volcado, el archivo oplog.bson contiene entradas para esas operaciones, cada una con un registro de hora. Puede utilizar OplogLSN.sh para capturar el primer y el último registro de hora de la operación o convertirlo en un archivo JSON para inspección manual, como se muestra en el paso anterior.
  3. Ejecute la utilidad de restauración MongoDB. Utilice la utilidad mongorestore para restaurar las recopilaciones seleccionadas del volcado a la instancia de destino MongoDB:
    $ ./mongorestore --uri="mongodb://localhost:27021" --nsInclude=testDB.coll1 --nsInclude=testDB.coll2 /path/to/dump -v

    El comando devuelve lo siguiente:

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

    El comando restaura los datos, los metadatos y las definiciones de índice para la recopilación especificada en la instancia de destino MongoDB/ORDS. Por ejemplo, coll1 y coll2 en la base de datos testDB como se muestra en la salida anterior.

  4. Cree y ejecute una extracción de captura de datos de cambio (CDC) en el despliegue de Big Data de origen para MongoDB. Inicie el Extract de CDC MongoDB desde el primer registro de hora de operación (primer LSN) obtenido en el paso 2b. Esto garantiza que CDC Extract capture las operaciones que se producen después de que se inicie el proceso de volcado.
  5. Cree y ejecute un MongoDB Replicat.
    1. Utilice el archivo de pista de CDC generado del paso 4.
    2. Defina oplongReplayLastLsn en el último registro de hora de operación (Último LSN) obtenido en el paso 2b, o la ruta a oplog.bson y el último LSN se obtiene automáticamente. Esto garantiza que Replicat se ejecute en modo oplong-replay, evitando colisiones y garantizando un inicio preciso sin pérdida ni duplicación de datos. Después de procesar el último registro de hora, el Replicat continúa en modo normal.

Sugerencias

Estos son algunos consejos para garantizar que la migración se realice sin problemas:

  • Se recomienda usar mongodb-database-tools versión 100.10.0 o inferior.
  • Antes de ejecutar mongodump, limpie la carpeta de volcado existente para suprimir los datos inconsistentes.
  • Restauración MongoDB: se pueden replicar varias recopilaciones de una base de datos mediante varias opciones --nsInclude en el comando mongorestore. Sin embargo, las varias bases de datos ORDS no se pueden restaurar mediante varios comandos --nsInclude. Debe utilizar varios comandos de restauración, uno para cada base de datos que se va a restaurar.