0

I have transferred my mongodb database to a new computer and am having trouble opening the database. I don't get any errors, it just won't show the 'finance' database. Here is the response when I say to repair the data:

PS <path>> & "<path>\mongod.exe" --dbpath="<path>\mongoDB\data" --repair
2018-12-26T10:54:15.393-0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2018-12-26T10:54:15.397-0800 I CONTROL  [initandlisten] MongoDB starting : pid=3572 port=27017 dbpath=<path>mongoDB\data 64-bit
host=Laptop
2018-12-26T10:54:15.397-0800 I CONTROL  [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2018-12-26T10:54:15.398-0800 I CONTROL  [initandlisten] db version v4.0.5
2018-12-26T10:54:15.398-0800 I CONTROL  [initandlisten] git version: 3739429dd92b92d1b0ab120911a23d50bf03c412
2018-12-26T10:54:15.399-0800 I CONTROL  [initandlisten] allocator: tcmalloc
2018-12-26T10:54:15.399-0800 I CONTROL  [initandlisten] modules: none
2018-12-26T10:54:15.400-0800 I CONTROL  [initandlisten] build environment:
2018-12-26T10:54:15.401-0800 I CONTROL  [initandlisten]     distmod: 2008plus-ssl
2018-12-26T10:54:15.401-0800 I CONTROL  [initandlisten]     distarch: x86_64
2018-12-26T10:54:15.402-0800 I CONTROL  [initandlisten]     target_arch: x86_64
2018-12-26T10:54:15.402-0800 I CONTROL  [initandlisten] options: { repair: true, storage: { dbPath: "<path>\mongoDB\data" } }
2018-12-26T10:54:15.403-0800 W STORAGE  [initandlisten] Detected unclean shutdown - <path>\mongoDB\data\mongod.lock is not empty.
2018-12-26T10:54:15.417-0800 I STORAGE  [initandlisten] Detected data files in <path>mongoDB\data created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2018-12-26T10:54:15.417-0800 W STORAGE  [initandlisten] Recovering data from the last clean checkpoint.
2018-12-26T10:54:15.418-0800 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=3427M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2018-12-26T10:54:15.842-0800 I STORAGE  [initandlisten] WiredTiger message [1545850455:841284][3572:140733260381264], txn-recover: Main recovery loop: starting at 16/256 to 17/256
2018-12-26T10:54:15.844-0800 I STORAGE  [initandlisten] WiredTiger message [1545850455:843264][3572:140733260381264], txn-recover: Recovering log 16 through 17
2018-12-26T10:54:16.101-0800 I STORAGE  [initandlisten] WiredTiger message [1545850456:100261][3572:140733260381264], file:sizeStorer.wt, txn-recover: Recovering log 17 through 17
2018-12-26T10:54:16.264-0800 I STORAGE  [initandlisten] WiredTiger message [1545850456:264292][3572:140733260381264], file:sizeStorer.wt, txn-recover: Set global recovery timestamp: 0
2018-12-26T10:54:16.365-0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2018-12-26T10:54:16.369-0800 I STORAGE  [initandlisten] Repairing size cache
2018-12-26T10:54:16.409-0800 I STORAGE  [initandlisten] Verify succeeded on uri table:sizeStorer. Not salvaging.
2018-12-26T10:54:16.415-0800 I STORAGE  [initandlisten] Repairing catalog metadata
2018-12-26T10:54:16.442-0800 I STORAGE  [initandlisten] Verify succeeded on uri table:_mdb_catalog. Not salvaging.
2018-12-26T10:54:16.482-0800 I CONTROL  [initandlisten]
2018-12-26T10:54:16.482-0800 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2018-12-26T10:54:16.483-0800 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2018-12-26T10:54:16.483-0800 I CONTROL  [initandlisten]
2018-12-26T10:54:16.483-0800 I CONTROL  [initandlisten] ** WARNING: This server is bound to localhost.
2018-12-26T10:54:16.484-0800 I CONTROL  [initandlisten] **          Remote systems will be unable to connect to this server.
2018-12-26T10:54:16.485-0800 I CONTROL  [initandlisten] **          Start the server with --bind_ip <address> to specify which IP
2018-12-26T10:54:16.485-0800 I CONTROL  [initandlisten] **          addresses it should serve responses from, or with --bind_ip_all to
2018-12-26T10:54:16.485-0800 I CONTROL  [initandlisten] **          bind to all interfaces. If this behavior is desired, start the
2018-12-26T10:54:16.486-0800 I CONTROL  [initandlisten] **          server with --bind_ip 127.0.0.1 to disable this warning.
2018-12-26T10:54:16.486-0800 I CONTROL  [initandlisten]
2018-12-26T13:54:16.489-0500 I STORAGE  [initandlisten] repairDatabase admin
2018-12-26T13:54:16.489-0500 I STORAGE  [initandlisten] Repairing collection admin.system.version
2018-12-26T13:54:16.491-0500 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-0--1220489030660904118. Not salvaging.
2018-12-26T13:54:16.531-0500 I INDEX    [initandlisten] build index on: admin.system.version properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "admin.system.version" }
2018-12-26T13:54:16.532-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-26T13:54:16.568-0500 I STORAGE  [initandlisten] repairDatabase config
2018-12-26T13:54:16.568-0500 I STORAGE  [initandlisten] Repairing collection config.system.sessions
2018-12-26T13:54:16.570-0500 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-4--1220489030660904118. Not salvaging.
2018-12-26T13:54:16.609-0500 I INDEX    [initandlisten] build index on: config.system.sessions properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "config.system.sessions" }
2018-12-26T13:54:16.610-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 250 megabytes of RAM
2018-12-26T13:54:16.640-0500 I INDEX    [initandlisten] build index on: config.system.sessions properties: { v: 2, key: { lastUse: 1 }, name: "lsidTTLIndex", ns: "config.system.sessions", expireAfterSeconds: 1800 }
2018-12-26T13:54:16.640-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 250 megabytes of RAM
2018-12-26T13:54:16.703-0500 I STORAGE  [initandlisten] repairDatabase finance
2018-12-26T13:54:16.703-0500 I STORAGE  [initandlisten] Repairing collection finance.accounts
2018-12-26T13:54:16.704-0500 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-0--4281080963220342640. Not salvaging.
2018-12-26T13:54:16.744-0500 I INDEX    [initandlisten] build index on: finance.accounts properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "finance.accounts" }
2018-12-26T13:54:16.744-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-26T13:54:16.773-0500 I STORAGE  [initandlisten] Repairing collection finance.categories
2018-12-26T13:54:16.775-0500 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-7--1220489030660904118. Not salvaging.
2018-12-26T13:54:16.810-0500 I INDEX    [initandlisten] build index on: finance.categories properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "finance.categories" }
2018-12-26T13:54:16.811-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-26T13:54:16.844-0500 I STORAGE  [initandlisten] Repairing collection finance.transactions
2018-12-26T13:54:16.851-0500 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-0--5757744516857351961. Not salvaging.
2018-12-26T13:54:16.892-0500 I INDEX    [initandlisten] build index on: finance.transactions properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "finance.transactions" }
2018-12-26T13:54:16.892-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-26T13:54:16.969-0500 I STORAGE  [initandlisten] repairDatabase local
2018-12-26T13:54:16.970-0500 I STORAGE  [initandlisten] Repairing collection local.startup_log
2018-12-26T13:54:16.972-0500 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-2--1220489030660904118. Not salvaging.
2018-12-26T13:54:17.012-0500 I INDEX    [initandlisten] build index on: local.startup_log properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "local.startup_log" }
2018-12-26T13:54:17.012-0500 I INDEX    [initandlisten]          building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2018-12-26T13:54:17.080-0500 W ASIO     [initandlisten] No TransportLayer configured during NetworkInterface startup
2018-12-26T13:54:17.082-0500 I STORAGE  [initandlisten] finished checking dbs
2018-12-26T13:54:17.083-0500 I STORAGE  [initandlisten] WiredTigerKVEngine shutting down
2018-12-26T13:54:17.391-0500 I STORAGE  [initandlisten] shutdown: removing fs lock...
2018-12-26T13:54:17.392-0500 I CONTROL  [initandlisten] now exiting
2018-12-26T13:54:17.392-0500 I CONTROL  [initandlisten] shutting down with code:0
  • How did you take your backup of the original dbpath and what specific MongoDB server version was that? There should be no need to run repair if you have a good backup; this is really intended as a last resort command to salvage data from a corrupt dbpath. What tool and version are you using to check the finance database; can you include the command line or steps you took to verify? If you are using the mongo shell, please also edit your question to include version() and db.version(). – Stennie Dec 27 '18 at 0:54
  • This is where my ignorance manifests itself. I was trying to move the database from my prior computer to my new computer - I thought it was all contained just within the /data/ folder and so I did a copy/paste of it without a full backup. I'm just learning so this was merely a test database I can relatively easily recreate. – BobtheMagicMoose Dec 29 '18 at 15:11
  • 1
    Backup by copying underlying data files is a supported approach but there are some important caveats to be aware of: you need to stop or quiesce writes to the data files (stopping the mongod process would be safest) and ideally restore the files on the same release series of MongoDB (i.e. 4.0.x to 4.0.y). When changing major releases of MongoDB you need to consider upgrade/downgrade scenarios. The "Detected unclean shutdown" startup message suggests you took a backup from a running mongod. – Stennie Dec 30 '18 at 5:23
  • Thanks for educating me! That's really helpful to know. – BobtheMagicMoose Dec 30 '18 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.