Uploaded image for project: 'MongoDB ETL Tools'
  1. MongoDB ETL Tools
  2. TOOLS-2215

Problème UUID restauration OPLOGS

    XMLWordPrintable

    Details

    • Type: Question
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Cannot Reproduce
    • Affects Version/s: 3.6.6
    • Fix Version/s: None
    • Component/s: mongodump, mongorestore
    • Labels:
      None
    • Environment:
      Docker sous Linux
    • Case:

      Description

      Bonjour

      Sur une application avec MongoDb, nous effectuons une sauvegarde FULL le soir à 22h30 et des sauvegardes OPLOGS (incrémentales) toutes les heures.

      Nous devons effectuer un test de restauration en cas de perte de données.
      Voici les commandes aux diverses étapes :

      Sauvegarde MongoDB
      FULL :

      command: sh -c 'mongodump -h \{{MONGOREPLICA}} --sslAllowInvalidHostnames --ssl --sslCAFile "/data/certs/PSA_cacerts.crt" -u \{{MONGO_ADMIN}} -p \{{MONGO_ADMIN_PWD}} --authenticationDatabase "admin" --oplog --out=\{{UNXAPPLI}}/restore/20190204T223012_FULL_mongo_save'

      OPLOG :

      command: sh -c 'mongodump -h {{MONGOREPLICA}} --sslAllowInvalidHostnames --ssl --sslCAFile "/data/certs/PSA_cacerts.crt" -u {{MONGO_ADMIN}} -p {{MONGO_ADMIN_PWD}} --authenticationDatabase "admin" -d local -c oplog.rs --out={{UNXAPPLI}}/restore/20190205T100009_OPLOGS_mongo_save'

      Restauration MongoDb
      FULL :

      command: sh -c 'mongorestore -h {{MONGOREPLICA}} --sslAllowInvalidHostnames --ssl --sslCAFile "/data/certs/PSA_cacerts.crt" -u {{MONGO_ADMIN}} -p {{MONGO_ADMIN_PWD}} --authenticationDatabase "admin" --drop --oplogReplay {{UNXAPPLI}}/restore/20190204T223012_FULL_mongo_save'
       
      docker logs yvaxxxxx/validemail_restore_FULL_database
      2019-02-05T10:24:13.964+0000    preparing collections to restore from
      2019-02-05T10:24:13.987+0000    reading metadata for vdl.email from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/email.metadata.json
      2019-02-05T10:24:14.010+0000    restoring vdl.email from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/email.bson
      2019-02-05T10:24:14.024+0000    reading metadata for admin.tempusers from /users/vdl00/restore/20190204T223012_FULL_mongo_save/admin/tempusers.metadata.json
      2019-02-05T10:24:14.027+0000    reading metadata for vdl.fs.files from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/fs.files.metadata.json
      2019-02-05T10:24:14.053+0000    restoring indexes for collection vdl.email from metadata
      2019-02-05T10:24:14.061+0000    restoring admin.tempusers from /users/vdl00/restore/20190204T223012_FULL_mongo_save/admin/tempusers.bson
      2019-02-05T10:24:14.077+0000    restoring vdl.fs.files from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/fs.files.bson
      2019-02-05T10:24:14.078+0000    reading metadata for vdl.fs.chunks from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/fs.chunks.metadata.json
      2019-02-05T10:24:14.121+0000    no indexes to restore
      2019-02-05T10:24:14.121+0000    finished restoring admin.tempusers (2 documents)
      2019-02-05T10:24:14.136+0000    finished restoring vdl.email (4 documents)
      2019-02-05T10:24:14.165+0000    restoring vdl.fs.chunks from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/fs.chunks.bson
      2019-02-05T10:24:14.197+0000    reading metadata for vdl.healthCheck from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/healthCheck.metadata.json
      2019-02-05T10:24:14.223+0000    restoring vdl.healthCheck from /users/vdl00/restore/20190204T223012_FULL_mongo_save/vdl/healthCheck.bson
      2019-02-05T10:24:14.253+0000    restoring indexes for collection vdl.fs.files from metadata
      2019-02-05T10:24:14.272+0000    finished restoring vdl.fs.files (11 documents)
      2019-02-05T10:24:14.297+0000    restoring indexes for collection vdl.healthCheck from metadata
      2019-02-05T10:24:14.298+0000    restoring indexes for collection vdl.fs.chunks from metadata
      2019-02-05T10:24:14.316+0000    finished restoring vdl.healthCheck (1 document)
      2019-02-05T10:24:14.332+0000    finished restoring vdl.fs.chunks (11 documents)
      2019-02-05T10:24:14.332+0000    restoring users from /users/vdl00/restore/20190204T223012_FULL_mongo_save/admin/system.users.bson
      2019-02-05T10:24:14.407+0000    restoring roles from /users/vdl00/restore/20190204T223012_FULL_mongo_save/admin/system.roles.bson
      2019-02-05T10:24:14.479+0000    replaying oplog
      2019-02-05T10:24:14.482+0000    done

      OPLOGS :

      command: sh -c 'mongorestore -h {{MONGOREPLICA}} --sslAllowInvalidHostnames --ssl --sslCAFile "/data/certs/PSA_cacerts.crt" -u {{MONGO_ADMIN}} -p {{MONGO_ADMIN_PWD}} --authenticationDatabase "admin" --oplogReplay --oplogLimit 1548882000:1 {{UNXAPPLI}}/restore/20190205T100009_OPLOGS_mongo_save'
       
      docker logs yvaxxxxx/validemail_restore_OPLOGS_database
      2019-02-05T10:24:31.187+0000    preparing collections to restore from
      2019-02-05T10:24:31.193+0000    replaying oplog
      2019-02-05T10:24:31.214+0000    Failed: restore error: error applying oplog: applyOps: uuid must be a 16-byte binary field with UUID (4) subtype

      Je suppose que la restauration FULL de la base génère un nouvel UUID. Comment le conserver lors de la restauration FULL ou d'en spécifier un lors de la restauration OPLOGS?

      Merci d'avance pour votre aide

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                david.golden David Golden
                Reporter:
                christhof25 U251435
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: