在自有ARM系统上离线安装MongoDB的坎坷历程与解决方案

在ARM系统上离线安装MongoDB的坎坷历程与解决方案

在ARM架构设备上进行软件开发和部署时，数据库的安装和配置是关键环节。本文将详细分享我在ARM系统上离线安装MongoDB过程中遇到的各种问题及对应的解决方法，希望能为有相同经历的开发者提供一些参考。

环境背景

我所使用的设备是ARM架构的服务器，运行着基于linux内核的自有操作系统。由于网络环境限制，需要进行MongoDB的离线安装。最初的目标是安装MongoDB 5.0版本，以满足项目对数据库功能的需求。

安装尝试与问题

架构兼容性问题

为了解决依赖问题，但当执行mongod命令启动服务时，却出现了Illegal instruction (core dumped)错误。这表明MongoDB二进制文件尝试执行的指令集不被当前CPU支持。

通过lscpu命令查看CPU信息，确认了我的ARM设备CPU架构为aarch64。进一步分析发现，可能是由于较新的MongoDB版本使用了特定ARM64芯片才支持的高级指令集，而我的设备CPU不支持这些指令。

编译问题

考虑到可能是预编译的二进制文件与我的设备不兼容，我决定尝试从源代码编译MongoDB。从MongoDB官方GitHub仓库下载了5.0.15版本的源代码后，按照官方文档进行编译。在执行scons命令时，又遇到了一系列问题。

首先是缺少psutil Python模块，导致编译中断。这是因为MongoDB编译过程依赖该模块来获取系统信息。接着，在解决了psutil问题后，又出现了缺少yaml模块的错误，同样是因为编译依赖。

在解决了这些Python模块依赖问题后，又遇到了编译器版本不满足要求的问题。MongoDB编译要求使用GCC 8.2或更新版本的编译器，而我系统中默认的GCC版本较低。 — 没有继续升级GCC做编译。

解决方案

解决依赖缺失

针对依赖缺失问题，找一个同类型的aarch64系统。 拷贝系统中缺失的依赖库。

ln -s libbrotlicommon.so.1.0.7 /lib64/libbrotlicommon.so.1
ln -s libkeyutils.so.1.10 /lib64/libkeyutils.so.1
ln -s libpsl.so.5.3.3 /lib64/libpsl.so.5
ln -s libbrotlidec.so.1.0.7 /lib64/libbrotlidec.so.1
ln -s libkrb5.so.3.3 /lib64/libkrb5.so.3
ln -s libsasl2.so.3.0.0 /lib64/libsasl2.so.3
ln -s libcrypto.so.1.1.1f /lib64/libcrypto.so.1.1
ln -s libkrb5support.so.0.1 /lib64/libkrb5support.so.0
ln -s libssh.so.4.8.5 /lib64/libssh.so.4
ln -s libcurl.so.4.6.0 /lib64/libcurl.so.4
ln -s liblber-2.4.so.2.10.13 /lib64/liblber-2.4.so.2
ln -s libssl.so.1.1.1f /lib64/libssl.so.1.1
ln -s libgssapi_krb5.so.2.2 /lib64/libgssapi_krb5.so.2
ln -s libldap-2.4.so.2.10.13 /lib64/libldap-2.4.so.2
ln -s libunistring.so.2.1.0 /lib64/libunistring.so.2
ln -s libidn2.so.0.3.7 /lib64/libidn2.so.0
ln -s liblzma.so.5.2.5 /lib64/liblzma.so.5
ln -s libk5crypto.so.3.1 /lib64/libk5crypto.so.3
ln -s libnghttp2.so.14.20.0 /lib64/libnghttp2.so.14

解决架构兼容性

为了解决架构兼容性问题，我尝试了多种方法。首先，从MongoDB官方网站下载了不同版本的aarch64架构的RPM包，包括较旧的版本，希望能找到一个与我的CPU指令集兼容的版本。同时，考虑到使用容器化方案可以避免不同系统环境和CPU指令集的差异，我尝试使用Docker来安装MongoDB。

在拉取ARM架构的MongoDB Docker镜像时，又遇到了镜像版本与宿主机架构不匹配的问题。例如，在拉取arm64v8/mongo:5.0镜像时，出现了no matching manifest for linux/amd64 in the manifest list entries错误，原因是我的宿主机是aarch64架构，而不是amd64架构。通过正确拉取arm64v8/mongo:5.0镜像并启动容器后，依然遇到了Illegal instruction (core dumped)错误，提示我的CPU不支持ARMv8.2 - A或更高版本的特性，而MongoDB 5.0及以上版本需要该特性。

解决编译问题

对于编译过程中的问题，我按照以下步骤逐一解决。首先，安装缺失的Python模块。使用pip3 install psutil和pip3 install pyyaml命令分别安装了psutil和yaml模块。

对于编译器版本不满足要求的问题，我使用了软件集合（Software Collections，SCL）来安装高版本的GCC。在CentOS系统上，通过以下命令安装了devtoolset - 8软件集合，其中包含GCC 8系列的编译器：

sudo yum install -y centos-release-scl
sudo yum install -y devtoolset-8

然后通过scl enable devtoolset - 8 bash命令启用了GCC 8环境。 – 自有系统不支持，可以自己编译。应非自有环境和判断未必可以用，没有继续执行。

最终解决方案与确认

经过多次尝试和调整，我发现使用MongoDB 4.4.9版本可以在我的ARM系统上正常运行。在使用arm64v8/mongo:4.4.9镜像启动Docker容器后，成功进入容器并启动了MongoDB服务。

在容器内，使用以下命令启动MongoDB服务：

mongod --dbpath /data/db

为了验证MongoDB是否正常运行，使用mongo客户端连接到MongoDB服务器：

mongo

成功进入MongoDB的交互式shell，并能够执行一些简单的命令，如查看数据库列表：

show dbs

这表明MongoDB 4.4.9版本在我的ARM系统上已经成功安装并正常工作。

使用官网的aarch64系统架构的mongodb4.4.9对应版本可以完成系统的兼容运行。

总结

在ARM系统上进行MongoDB的离线安装过程中，遇到了依赖缺失、架构兼容性以及编译等多方面的问题。通过不断尝试不同的解决方案，包括调整仓库配置、更换不同版本的安装包、使用容器化技术以及解决编译依赖等，最终找到了适合我设备的MongoDB版本。希望本文的经验分享能够帮助其他开发者在类似的环境中顺利完成MongoDB的安装和配置。