Problem with version compatibility/upgrades

I am running in a Windows 10 environment.

I have previously/recently been using MongoDB 3.2.21 Community Standalone to complete the M101-JS course (that is the version required for that course). All worked fine for that course.

As part of the setup for this M001 course, I installed MongoDB 4.0.4 Enterprise in a separate directory and updated the PATH environment variable to point to it, as instructed. I also installed Compass 1.16.1. All works fine for the M001 course.

However, I am now unable to use/access the data from my prior 3.2.21 installation. None of the databases I previously created show up in the shell. Can anyone provide insight into what I need to do to access my old data?

Note: I have tried reverting the PATH environment variable to point back to the original 3.2 installation directory. “mongod --version” indicates version 3.2.21. When I start the shell, it also indicates version 3.2.21.
However, the mongo shell appears that it may be mixing settings with 4.0.4, because the shell prompt is “MongoDB Enterprise >” (which is different from when I was previously using 3.2.21).

What am I missing?

Also, I didn’t explicitly upgrade any of my 3.2.21 databases. I think they were originally set up with MMAPv1 (the default in 3.2.21??).
Now when I explicitly use “mongodb --storageEngine MMAPv1”, I get a message saying that WiredTiger databases are found and so I can’t select MMAPv1 storage engine. Presumably because the 4.0.4 version has put files from this course in the same location. Again, any insights??

Hi @Carl_62563,

However, I am now unable to use/access the data from my prior 3.2.21 installation. None of the databases I previously created show up in the shell. Can anyone provide insight into what I need to do to access my old data?

Between 3.2 and 4.0 there are some backward incompatibility features that require you to first upgrade the instances and, potentially the dataset, so that you can load 3.2 data into a 4.0 mongod instance.
Have you tried to load the same --dbpath used by the 3.2 binary with the 4.0 binary?

path_to_32\mongod --dbapth c:\data

...

path_to_40\mongod --dbpath c:\data

You can always check with version you are running, the mongo shell and the server that you are connected to versions:

# shell version
mongo --version 

# server version 
mongo --eval 'db.version()'

Now when I explicitly use “mongodb --storageEngine MMAPv1”, I get a message saying that WiredTiger databases are found and so I can’t select MMAPv1 storage engine. Presumably because the 4.0.4 version has put files from this course in the same location. Again, any insights??

mongodb --storageEngine MMAPv1 perhaps you meant mongod --storageEngine MMAPv1.

Be aware that MMAPv1 has been deprecated!

Can you paste the exact error message?

N.

Thank you for the quick response, Norberto!

Unfortunately, I’m still confused as to what is happening. Here’s some more info on exactly what I’m seeing, with my current PATH variable set to use the 3.2 version (ie. C:\Program Files\MongoDB\Server\3.2\bin):

C:\Users\Carl> mongo --version
MongoDB shell version: 3.2.21

C:\Users\Carl> mongo --eval ‘db.version()’
MongoDB shell version: 3.2.21
connecting to test
db.version()

Since it doesn’t appear (to me) to respond with the database version, does that mean it’s not finding the database? Note that there is no db named “test” in the list of 4.0 databases. There was in the 3.2 databases.

If I specify a db that I know exists in the 4.0 database (eg. “admin”), then I get the following:

C:\Users\Carl> mongo admin --eval 'db.version()"
MongoDB shell version: 3.2.21
connecting to: admin
4.0.4

Here’s the output when I start mongod. It seems normal, but then the shell doesn’t find my 3.2 databases. It does find the 4.0 databases:

C:\Users\Carl> mongod
2018-12-05T11:33:57.105-0800 I CONTROL [initandlisten] MongoDB starting : pid=18680 port=27017 dbpath=C:\data\db\ 64-bit host=Carl-PC3
2018-12-05T11:33:57.107-0800 I CONTROL [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2018-12-05T11:33:57.107-0800 I CONTROL [initandlisten] db version v3.2.21
2018-12-05T11:33:57.107-0800 I CONTROL [initandlisten] git version: 1ab1010737145ba3761318508ff65ba74dfe8155
2018-12-05T11:33:57.108-0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2o-fips 27 Mar 2018
2018-12-05T11:33:57.108-0800 I CONTROL [initandlisten] allocator: tcmalloc
2018-12-05T11:33:57.109-0800 I CONTROL [initandlisten] modules: none
2018-12-05T11:33:57.109-0800 I CONTROL [initandlisten] build environment:
2018-12-05T11:33:57.109-0800 I CONTROL [initandlisten] distmod: 2008plus-ssl
2018-12-05T11:33:57.109-0800 I CONTROL [initandlisten] distarch: x86_64
2018-12-05T11:33:57.110-0800 I CONTROL [initandlisten] target_arch: x86_64
2018-12-05T11:33:57.110-0800 I CONTROL [initandlisten] options: {}
2018-12-05T11:33:57.112-0800 I - [initandlisten] Detected data files in C:\data\db\ created by the ‘wiredTiger’ storage engine, so setting the active storage engine to ‘wiredTiger’.
2018-12-05T11:33:57.113-0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=4G,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),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),verbose=(recovery_progress),
2018-12-05T11:33:57.341-0800 I STORAGE [initandlisten] WiredTiger [1544038437:341573][18680:140723244186704], txn-recover: Main recovery loop: starting at 22/6656
2018-12-05T11:33:57.486-0800 I STORAGE [initandlisten] WiredTiger [1544038437:486297][18680:140723244186704], txn-recover: Recovering log 22 through 23
2018-12-05T11:33:57.496-0800 I STORAGE [initandlisten] WiredTiger [1544038437:496277][18680:140723244186704], txn-recover: Recovering log 23 through 23
2018-12-05T11:33:57.863-0800 I NETWORK [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2018-12-05T11:33:58.265-0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory ‘C:/data/db/diagnostic.data’
2018-12-05T11:33:58.266-0800 I NETWORK [initandlisten] waiting for connections on port 27017

Here’s what I get from the 3.2 shell when I connect to that:

C:\Users\Carl> mongo
MongoDB shell version: 3.2.21
connecting to: test
Server has startup warnings:
2018-12-04T23:17:33.582-0800 I CONTROL [initandlisten]
2018-12-04T23:17:33.582-0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2018-12-04T23:17:33.583-0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2018-12-04T23:17:33.583-0800 I CONTROL [initandlisten]

MongoDB Enterprise > show dbs
admin 0.000GB
config 0.000GB
local 0.000GB
MongoDB Enterprise >

The shell prompt (“MongoDB Enterprise>”) appears related to 4.0. Is that a reflection of the shell version, or is it an artifact of the db version?

Regarding the storageEngine parameter, you were correct… I made a typo. I meant “mongod --storageEngine=mmapv1”. I am aware that MMAPv1 has been deprecated. I don’t particularly want/need to use MMAPv1, I am just trying to get access to the data. It seems that MMAPv1 should still work with the 3.2 version that is still installed. Here’s what I get when I try that:

C:\DATA\db> mongod --storageEngine=mmapv1
2018-12-05T11:52:15.745-0800 I CONTROL [initandlisten] MongoDB starting : pid=19436 port=27017 dbpath=C:\data\db\ 64-bit host=Carl-PC3
2018-12-05T11:52:15.748-0800 I CONTROL [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2018-12-05T11:52:15.748-0800 I CONTROL [initandlisten] db version v3.2.21
2018-12-05T11:52:15.748-0800 I CONTROL [initandlisten] git version: 1ab1010737145ba3761318508ff65ba74dfe8155
2018-12-05T11:52:15.749-0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2o-fips 27 Mar 2018
2018-12-05T11:52:15.749-0800 I CONTROL [initandlisten] allocator: tcmalloc
2018-12-05T11:52:15.749-0800 I CONTROL [initandlisten] modules: none
2018-12-05T11:52:15.750-0800 I CONTROL [initandlisten] build environment:
2018-12-05T11:52:15.750-0800 I CONTROL [initandlisten] distmod: 2008plus-ssl
2018-12-05T11:52:15.750-0800 I CONTROL [initandlisten] distarch: x86_64
2018-12-05T11:52:15.751-0800 I CONTROL [initandlisten] target_arch: x86_64
2018-12-05T11:52:15.751-0800 I CONTROL [initandlisten] options: { storage: { engine: “mmapv1” } }
2018-12-05T11:52:15.758-0800 I STORAGE [initandlisten] exception in initAndListen: 28662 Cannot start server. Detected data files in C:\data\db\ created by the ‘wiredTiger’ storage engine, but the specified storage engine was ‘mmapv1’., terminating
2018-12-05T11:52:15.759-0800 I CONTROL [initandlisten] dbexit: rc: 100

Here are the contents of the db directory:

C:\DATA\db> dir
Volume in drive C is OS
Volume Serial Number is xxxx-xxxx

Directory of c:\DATA\db

12/05/2018 11:35 AM .
12/05/2018 11:35 AM …
12/05/2018 11:34 AM 36,864 collection-0–3388674877222056225.wt
12/05/2018 11:33 AM 16,384 collection-0-4319827844018791345.wt
12/05/2018 11:33 AM 36,864 collection-0-8407487927734999823.wt
12/05/2018 11:33 AM 36,864 collection-10-7025212375832626498.wt
12/05/2018 11:33 AM 73,728 collection-15–2292466275795285947.wt
12/05/2018 11:33 AM 16,384 collection-2–3388674877222056225.wt
12/05/2018 11:33 AM 35,549,184 collection-2–415033544786474886.wt
12/05/2018 11:33 AM 16,384 collection-2-4319827844018791345.wt
12/05/2018 11:33 AM 221,184 collection-4–3388674877222056225.wt
12/05/2018 11:33 AM 36,864 collection-4–415033544786474886.wt
12/05/2018 11:33 AM 16,384 collection-4-4319827844018791345.wt
12/05/2018 11:33 AM 45,056 collection-4-8407487927734999823.wt
12/05/2018 11:33 AM 36,864 collection-8–2292466275795285947.wt
12/05/2018 11:33 AM 45,056 collection-8-7025212375832626498.wt
12/05/2018 11:33 AM 1,150,976 collection-8-8407487927734999823.wt
12/05/2018 11:36 AM diagnostic.data
12/05/2018 11:34 AM 36,864 index-1–3388674877222056225.wt
10/24/2018 07:42 PM 16,384 index-1-4319827844018791345.wt
10/29/2018 05:41 PM 16,384 index-1-8407487927734999823.wt
11/17/2018 09:43 PM 16,384 index-10–2292466275795285947.wt
11/17/2018 10:42 PM 16,384 index-11–2292466275795285947.wt
12/02/2018 12:01 AM 16,384 index-11-7025212375832626498.wt
11/17/2018 09:44 PM 16,384 index-12–2292466275795285947.wt
12/02/2018 12:01 AM 24,576 index-12-7025212375832626498.wt
11/17/2018 09:44 PM 16,384 index-13–2292466275795285947.wt
11/17/2018 09:45 PM 16,384 index-14–2292466275795285947.wt
11/17/2018 10:42 PM 24,576 index-16–2292466275795285947.wt
10/21/2018 10:20 PM 16,384 index-3–3388674877222056225.wt
11/23/2018 03:29 PM 180,224 index-3–415033544786474886.wt
10/24/2018 07:42 PM 16,384 index-3-4319827844018791345.wt
11/10/2018 06:20 PM 69,632 index-5–3388674877222056225.wt
11/23/2018 03:29 PM 16,384 index-5–415033544786474886.wt
10/24/2018 07:42 PM 16,384 index-5-4319827844018791345.wt
10/29/2018 05:41 PM 16,384 index-5-8407487927734999823.wt
11/17/2018 10:42 PM 36,864 index-9–2292466275795285947.wt
12/02/2018 12:01 AM 16,384 index-9-7025212375832626498.wt
10/29/2018 05:41 PM 40,960 index-9-8407487927734999823.wt
12/05/2018 11:34 AM journal
12/05/2018 11:33 AM 6 mongod.lock
12/05/2018 11:35 AM 36,864 sizeStorer.wt
10/21/2018 09:32 PM 95 storage.bson
10/21/2018 09:32 PM 49 WiredTiger
10/21/2018 09:32 PM 21 WiredTiger.lock
12/05/2018 11:35 AM 1,002 WiredTiger.turtle
12/05/2018 11:35 AM 159,744 WiredTiger.wt
12/05/2018 11:33 AM 4,096 WiredTigerLAS.wt
12/05/2018 11:33 AM 36,864 _mdb_catalog.wt
45 File(s) 38,216,853 bytes
4 Dir(s) 67,813,380,096 bytes free

So to me it looks like the 4.0 install (which I did yesterday, following the directions from the M001 course) used the same db directory as 3.2. And since it did that, I can no longer access the 3.2 data. Is that right? Can databases from the two versions not co-exist in the same directory? If they can’t, how can I tease them apart? As you can see from the directory listing, some of the “WiredTiger” files pre-date my installation of 4.0, so I’m not sure how to separate the two databases.

Also, did the 4.0 install change/update the 3.2 databases? I’m guessing not. If updating the databases is a necessary step in order to get things working, please point me to the directions on how to do that with my current mixed version situation. Since I am have completed the M101-JS course, I no longer need to be using 3.2. I am happy to convert/update everything to 4.0. I just don’t know how to make that happen.

Thanks for your help!

Hi @Carl_62563,

So let’s go step by step:

  • You have installed locally MongoDB 3.2.21, both mongo shell and mongod

C:\Users\Carl> mongo --version
MongoDB shell version: 3.2.21

C:\Users\Carl> mongod
2018-12-05T11:33:57.105-0800 I CONTROL [initandlisten] MongoDB starting : pid=18680 port=27017 dbpath=C:\data\db\ 64-bit host=Carl-PC3
2018-12-05T11:33:57.107-0800 I CONTROL [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2018-12-05T11:33:57.107-0800 I CONTROL [initandlisten] db version v3.2.21

This is the binary version that you are running locally.

The dataset, that you have used for the previous course, that you are trying to access to, will not work with MMAPv1 since the this was loaded into a WiredTiger instance,

that’s why when you run this command it fails:

How do I know that you previously used WT instead of MMAPv1? The file database collection files tell me that (amongst other things)

12/05/2018 11:34 AM 36,864 collection-0–3388674877222056225.wt

You can reload all of this information using 4.0. (which does not seem to be available on your PATH from the commands you’ve show us) by upgrading your local MongoDB installed version.
Follow this upgrade tutorial for better guidance


That is not what the logs are telling us. The mongod version that you have currently installed seems to be 3.2.21. However, if you upgrade to 4.0 it will, by default, use the same dbpath as prior MongoDB versions running in your machine (in your case c:\DATA\db)

That should not be a problem. However, given that you have not followed the proper upgrade procedure, this might have caused some issues in the database files.
I’m going to run a few tests to see if can reproduce this scenario.
In any case, if there is data that cannot be loaded by the 4.0 mongod you should be able to see it in the logs with an WARNING/ERROR message.

Two different instance versions, 3.2 and 4.0, can infact share the same dbpath, but not concurrently.

You can do this by specifying a different dbpath.

There are backward incompatible features between versions of MongoDB. Again, follow the upgrade process tutorial

For M001, we recommend you to use a MongoDB Atlas cluster, instead of local installations. You can still run and install everything locally, however we recommend using Atlas given that all the course material was designed for that environment, which avoids issues like these.

N.

Norberto, sorry, I’m still a bit confused by your response.

Let me restate my situation, and perhaps that will help us both understand better what is going on:

  • I had installed 3.2 Standalone for a prior course and was using that for some personal development projects.

  • For this M001 course I installed 4.0 Enterprise. The installation of the binaries was into a different directory, so I assumed this would work as a parallel installation, without having to upgrade my other installation.

  • I am successfully using 4.0 Enterprise with Atlas and Compass for the M001 course. I am not currently trying to use a local database for the M001 course.

  • Since installing 4.0 Enterprise, I am unable to access the local databases that I had previously been using with 3.2 for development.

  • The databases I created using 3.2 are/were in the C:\DATA\db directory, which was the default (and seems to also be the default for 4.0).

  • I have tried accessing my databases both through 4.0 (by setting the PATH system env variable to point to its binaries) and through 3.2 (by separately setting PATH to point to its binaries. ie. reset PATH and rebooted Windows). I have been unsuccessful in both cases.

  • When I start mongo/mongod 3.2, the databases do not appear.

  • When I start mongod 4.0, I get the following, which says I must upgrade the databases:

C:\Users\Carl> mongod
2018-12-07T11:06:01.929-0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols ‘none’
2018-12-07T11:06:02.939-0800 I CONTROL [initandlisten] MongoDB starting : pid=11832 port=27017 dbpath=C:\data\db\ 64-bit host=Carl-PC3
2018-12-07T11:06:02.940-0800 I CONTROL [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2018-12-07T11:06:02.940-0800 I CONTROL [initandlisten] db version v4.0.4
2018-12-07T11:06:02.941-0800 I CONTROL [initandlisten] git version: f288a3bdf201007f3693c58e140056adf8b04839
2018-12-07T11:06:02.941-0800 I CONTROL [initandlisten] allocator: tcmalloc
2018-12-07T11:06:02.941-0800 I CONTROL [initandlisten] modules: enterprise
2018-12-07T11:06:02.942-0800 I CONTROL [initandlisten] build environment:
2018-12-07T11:06:02.942-0800 I CONTROL [initandlisten] distmod: windows-64
2018-12-07T11:06:02.943-0800 I CONTROL [initandlisten] distarch: x86_64
2018-12-07T11:06:02.943-0800 I CONTROL [initandlisten] target_arch: x86_64
2018-12-07T11:06:02.943-0800 I CONTROL [initandlisten] options: {}
2018-12-07T11:06:02.954-0800 I STORAGE [initandlisten] Detected data files in C:\data\db\ created by the ‘wiredTiger’ storage engine, so setting the active storage engine to ‘wiredTiger’.
2018-12-07T11:06:02.955-0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=3523M,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-07T11:06:03.359-0800 I STORAGE [initandlisten] WiredTiger message [1544209563:358358][11832:140721672174672], txn-recover: Main recovery loop: starting at 27/768 to 28/256
2018-12-07T11:06:03.654-0800 I STORAGE [initandlisten] WiredTiger message [1544209563:654176][11832:140721672174672], txn-recover: Recovering log 27 through 28
2018-12-07T11:06:03.835-0800 I STORAGE [initandlisten] WiredTiger message [1544209563:835064][11832:140721672174672], txn-recover: Recovering log 28 through 28
2018-12-07T11:06:03.984-0800 I STORAGE [initandlisten] WiredTiger message [1544209563:983974][11832:140721672174672], txn-recover: Set global recovery timestamp: 0
2018-12-07T11:06:04.027-0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2018-12-07T11:06:04.408-0800 I CONTROL [initandlisten]
2018-12-07T11:06:04.408-0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2018-12-07T11:06:04.408-0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2018-12-07T11:06:04.409-0800 I CONTROL [initandlisten]
2018-12-07T11:06:04.409-0800 I CONTROL [initandlisten] ** WARNING: This server is bound to localhost.
2018-12-07T11:06:04.410-0800 I CONTROL [initandlisten] ** Remote systems will be unable to connect to this server.
2018-12-07T11:06:04.410-0800 I CONTROL [initandlisten] ** Start the server with --bind_ip to specify which IP
2018-12-07T11:06:04.411-0800 I CONTROL [initandlisten] ** addresses it should serve responses from, or with --bind_ip_all to
2018-12-07T11:06:04.411-0800 I CONTROL [initandlisten] ** bind to all interfaces. If this behavior is desired, start the
2018-12-07T11:06:04.412-0800 I CONTROL [initandlisten] ** server with --bind_ip 127.0.0.1 to disable this warning.
2018-12-07T11:06:04.413-0800 I CONTROL [initandlisten]
2018-12-07T11:06:04.493-0800 F CONTROL [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: The data files need to be fully upgraded to version 3.6 before attempting an upgrade to 4.0; see http://dochub.mongodb.org/core/4.0-upgrade-fcv for more details.
2018-12-07T11:06:04.495-0800 I NETWORK [initandlisten] shutdown: going to close listening sockets…
2018-12-07T11:06:04.496-0800 I STORAGE [initandlisten] WiredTigerKVEngine shutting down
2018-12-07T11:06:04.566-0800 I STORAGE [initandlisten] Downgrading WiredTiger datafiles.
2018-12-07T11:06:05.202-0800 I STORAGE [initandlisten] WiredTiger message [1544209565:201182][11832:140721672174672], txn-recover: Main recovery loop: starting at 28/5760 to 29/256
2018-12-07T11:06:05.484-0800 I STORAGE [initandlisten] WiredTiger message [1544209565:484006][11832:140721672174672], txn-recover: Recovering log 28 through 29
2018-12-07T11:06:05.680-0800 I STORAGE [initandlisten] WiredTiger message [1544209565:679883][11832:140721672174672], txn-recover: Recovering log 29 through 29
2018-12-07T11:06:05.836-0800 I STORAGE [initandlisten] WiredTiger message [1544209565:835790][11832:140721672174672], txn-recover: Set global recovery timestamp: 0
2018-12-07T11:06:06.182-0800 I STORAGE [initandlisten] shutdown: removing fs lock…
2018-12-07T11:06:06.182-0800 I CONTROL [initandlisten] now exiting
2018-12-07T11:06:06.183-0800 I CONTROL [initandlisten] shutting down with code:62

  • I am not 100% certain, but I thought that the 3.2 databases I was using were created with MMAPv1. I am unclear if anything is required in order to convert them to use WiredTiger, but I have done nothing explicitly to convert/upgrade them.

  • I don’t particularly care which version of MongoDB I use (nor do I care which storage engine is used), I just need access to my prior data.

So, the question remains, how do I access these databases?

I have reviewed the “Upgrade Procedure” that you referenced (and which is also referenced in the above warning message). It indicates that prior to upgrading to 4.0, I must upgrade from 3.4 to 3.6. And the 3.4 instructions indicate I must upgrade from 3.2. However, most of the instructions are related to the binaries (which I have already installed in parallel) and feature incompatibilities, not to the data stores.

In any case, one of the prerequisites for the database upgrade is to run the following command:
db.adminCommand( { setFeatureCompatibilityVersion: “3.4” } ).

The problem is that I cannot access the db! So there is no way for me to set this and to proceed with any “upgrade”!!

I’m stuck and feeling quite frustrated because I haven’t been able to proceed with my project ever since I installed the 4.0 software for this M001 course. I don’t understand what the dependencies are or what the requirements are in order to get access to the databases I created using 3.2.

It seems that I should be able to access those databases using the 3.2 binaries, but I cannot. I don’t understand why not. Please help.

Can you please explain and provide detailed instructions on how to proceed in this situation (i.e. more detailed than are given on your website)? If you could tell me how to access the data using 3.2, then I could at least export it (and then import it into a 4.0 database, which might be easier than a 3-step “upgrade”).

Or, should I just consider my data irretrievably lost and begin the painful process of reconstructing it all from scratch?

I am also having a similar issue. I’m unable to use the mongo db shell with localhost after downloading the v4.0.5 enterprise version.

“The data files need to be fully upgraded to version 3.6 before attempting an upgrade to 4.0”

To get the mongod shell to work I had to downgrade to v3.4.19.
Any ideas how to solve this issue ?

I never got an answer and was not able to resolve the problem with accesssing my dataset.

I ended up deleteing all installs (including the data, which I couldn’t access any more anyway), then installing 4.x and reconstructing my dataset from scratch. I figured in the end that would be a faster way to get operational again, rather than waiting on non-responsive support. Fortunately this was not a production environment and it wasn’t critical to keep the exact same dataset. Just wasted a bunch of time.

Hi frank_04210,

Please follow Norberto’s instuctions.

If you have data files that used older versions of mongod will not be able to move to higher version like 4.0.5.

If data is not important or its test data, clean your /data/db directory and try again.

Note: Removing /data/db directory will remove all the data So, be careful with that.

Kanika