JH-Blog
!Qia-Software Software-Development

MongoDB: unknown or unsupported macOS version: :mountain_lion

  • UUID: f11ec397-b065-4416-a9ca-4b42626d1807
  • Links
    • [JH-Articles: The Digital World (uuid:33f7f425-cd8f-4458-a330-88f73b1f784d)]
    • [One!Contents: 20231205.MongoDB on macOS]

It was a suprise for me, that I got the following error message in the terminal, when I was trying to start my Qia-Articles program yesterday on my development MacBook Pro machine which runs the latest macOS Sonoma 14.1.2 I had justed updated to a few days ago.

pymongo.errors.ServerSelectionTimeoutError: localhost:27017: [Errno 61] Connection refused, Timeout: 30s, Topology Description: <TopologyDescription id: ..., topology_type: Single, servers: [<ServerDescription ('localhost', 27017) server_type: Unknown, rtt: None, error=AutoReconnect('localhost:27017: [Errno 61] Connection refused')>]>

Based on the error message information, it is not hard to guess the MongoDB engine on my macOS is not running. But how so? It indeed worked just well a few days ago before I updated my macOS. Well, old software stopped working on new OS. Well, it is usual in the digital world, and should not be a big surprise. I called out my terminal app again, did a bit inspection with the program HomeBrew such as brew list | grep mongo because I had a rough impression that I had installed the mongodb via HomeBrew, and got assured that the mongodb installed on my machine was not running. I tried to start the mongodb manully (mongodb, brew services start mongodb as well as more command such as brew info mongodb), which normally should not be necessary as mongodb should start with the OS (user login). It didn't work, as it was also the reason why mongodb was not running at the first place. But I repeatedly got an error message and the error message was interesting.

Error: mongodb: unknown or unsupported macOS version: :mountain_lion

Montain Lion (mountain_lion)? Yes, I am old enough to know there was version of macOS called as "OS X Mountain Lion". But according to Wikipedia, the latest release of OS X Mountainb Lion, 10.8.5 (Build 12F2560) was on August 13, 2015 (8 years ago), and my machine run macOS Sonoma 14.1.2 which was released on November 30, 2023. Well, then, I think a proper explanation could be like mongodb used a whitelist method to decide supported OS versions. Whitelist? Really? Sadly, it could very much likely be real! I do not think macOS 14.1.2 has removed some essential APIs from the last patch/minor version of the OS which resulted the mongodb error.

Okay, it was the time for me to upgrade the mongodb program as I can not make the existed mongodb start on the newly updated macOS. I shouldn't regret that I had updated my macOS because making minor and patch updates of OS should be the good practice in my opinion. But upgrading working database engine program is not something people usually do, especially when the database is only used on localhost (127.0.0.1), in such situation, security issues are not that critical. I don't remember when was the last time I updated the mongodb on my MacBook Pro before the mongodb update yesterday. But the version of mongodb before yesterday is 4.0.4 which was released on Nov 8, 2018 and a follwoing version 4.0.5 was released on Dec 20, 2018, so it was very much likely that I lastly installed or updated mongodb in November or December of 2018 which was around 5 years ago. Is 5 years a long time? Maybe yes for an ordinary software application for ordinary users, but no, not for a database engine. Anyway, let me just update my mongodb as the existed one did not work on the new OS. And I got another suprise - mongodb was remove from the HomeBrew core and I needed to use separated HomeBrew cask only for MongoDB (brew tap mongodb/brew). When something which was in HomeBrew core has been removed, it is already a sign that there must be something happened which makes the thing not as good as it was in the past. For mongodb, I knew or at least I had the impression, that it was about the change of licensing. By asking Bing CHAT "why mongodb was removed from homebrew core?", I got "MongoDB was removed from Homebrew’s core formulas because it switched to the Server Side Public License (SSPL), which is not an open-source license. This change led to MongoDB being removed from not only Homebrew but also from Red Hat Enterprise Linux and Fedora." By the way, my mustard on ChatGPT, it is a search engine with the ability to do proper summary. When there are 10 results saying yes and 2 results saying no, ChatGPT would very much likely to answer yes, no matter whether the yes is correct or not. It is an average ability agent but knows almost everything in a broad scope. Back to mongodb. By using the custom Homebrew tap (brew tap mongodb/brew) maintained by the MongoDB team, although not as convenient as when it was in the core, it is still easy to get mongodb installed (brew install mongodb-community), although under a new name mongodb-community. This is the sweet part. And then there comes the sweat part.

Normally, starting a CLI service program installed by HomeBrew is as easy as running brew services start mongodb-community. However, everything including the terminal output after entering the commond line just given as the example looked good, while at the same time mongodb engine was not running. Then there came the long debugging process which made me think that I needed to start composing this blog post.

I hadn't debugged any HomeBrew installed service for quite some time before yesterday. It took me some time to get back on track of how to properly debug a HomeBrew installed service. But this was by far not the challenging part. I got some useful information from the mongodb log (tail /usr/local/var/log/mongodb/mongo.log), which says:

"msg":"This version of MongoDB is too recent to start up on the existing data files. Try MongoDB 4.2 or earlier."

Good! MongoDB is not backward compatible and also has no built-in migration support in newer versions of MongoDB for data created by the older versions. So I tried to install the suggested version which is MongoDB 4.2 via brew install [email protected]. However, there came another error ("warning") message:

Warning: No available formula with the name "[email protected]". Did you mean [email protected], mongodb-community, [email protected] or [email protected]

Really? I then googled a while and got another sad conclusion. The [email protected] was there in the the custom Homebrew tap controlled by the MongoDB team but it was removed. Let me guess again about why. Why? Because supporting [email protected] for newer macOS is too much effort for the MongoDB team, or the MongoDB team would prefer users to use newer versions by leaving no way to install older versions. Basically, it is not bad that users are strongly suggested to use newer versions, but leaving no way to install older versions is another story. This is another point I think worth talking in my article titled as "The Digital/Internet World" about the controlling culture trend.

By asking Bing CHAT "How to migrate mongdo 4.0 data to be usable in the latest mongodb version?", the answer is as the following.

To migrate your MongoDB 4.0 data to the latest version, you need to follow a step-by-step upgrade process. According to the official MongoDB documentation and a Stack Overflow discussion, you cannot directly jump from 4.0 to the latest version. You need to upgrade in the following order: 4.0 -> 4.2 -> 4.4 -> 5.0 -> 6.02.

...
If you want to avoid this step-by-step upgrade process, another approach discussed on Stack Overflow involves creating a new MongoDB 6.0 instance and migrating all the data from the old instance to the new one. However, this approach has its own challenges and is not officially supported by MongoDB. It’s recommended to stick to the official upgrade path for the most reliable results.

Wooops, the Bing CHAT didn't give me the answer I was expecting this time (I asked again for the purpose of this blog post and I didn't take note for such a question yesterday). It doesn't even mention about mongodump and mongorestore which were mentioned yesterday and they are something I was expecting. No puzzles any more. I asked Bing CHAT on "Does mongodump requires a running mongodb engine?", and Bing gave the answer I would like to tell here:

Yes, mongodump requires a running MongoDB instance to operate. It connects to a mongod or mongos instance and exports data from the database. The operation involves reading all data to be dumped through the mongod process’ memory. Therefore, you need to have a running MongoDB instance to use mongodump.

Again, this is a blocked method that I cannot use because the existed mongodb 4.0.4 cannot run on my new OS.

Without easily installable mongodb 4.2 avaliable in HomeBrew and a stopped working mongodb 4.0.4 on my macOS 14.1.2, I got no easy choice but to give up on my existed mongodb 4.0.4 data. Luckily for me is that I didn't have very important data in mongodb 4.0.4, otherwise, I would need to spend many more unnecessary hours just trying to restore my existed data. But what if I am not alone here? What if someone else has much more important data in older versions fo mongodb. Do they need to downgrade the OS or do they need to make copies of the mongodb data and restore or export on another machine which has older OS and possibly works?

It is just sad that my data was intentionally locked by the MongoDB team. It may be unlocked without much efforts, like allowing installing [email protected] or making the latest mongodb with a built-in data migration ability.

Anyway, we cannot always assume others to do the job. What is my lesson here or what could be a suggestion to my dear readers who reached this part of the blog post.

  • Do database data exports more often
    • Like if I have done the mongodump the day before OS update, I would only need to lose the data updates happend after the export
  • If doing data exports is too much work, just choose better databse engines to use or feeling okay about losing data
    • To be honest, I will not do more frequent data exports because for most cases, it is just efforts without big value
  • As a compromise, last resort, upgrade the database engine in a proper interval
    • Like I think, upgrade the database engine once per year would be enough or once with the OS major upgrade

* cached version, generated at 2023-12-12 01:40:13 UTC.

Subscribe by RSS