ARM64 CentOS 7 源码编译 MySQL 5.7 完整实战指南

ARM64的机器这几年越来越多，尤其是云平台出了各种鲲鹏、飞腾、倚天之类的实例。但问题是，大量老业务还死在MySQL 5.7上，不能说升级就升级。最近我就在一台CentOS 7的ARM64服务器上折腾着把MySQL 5.7装起来，过程比x86上要麻烦不少。最核心的矛盾在于：官方RPM包根本没有ARM64版本的MySQL 5.7，CentOS官方源里也只到MariaDB和MySQL 8.0。如果业务对5.7有硬性要求，唯一稳妥的路就是源码编译。

这篇文章就把我整个实操过程完整梳理一遍，从环境确认、方案选型、编译参数、初始化配置到常见坑位排查，全串起来。如果你手上正好有ARM64架构的CentOS 7机器，且必须跑MySQL 5.7，这篇文章可以直接照着抄。

1. 环境确认与方案选型

动手之前先别急着装，有几个问题得先搞清楚：你的机器架构对不对？系统版本到底是不是CentOS 7？yum源里到底有没有可用的MySQL 5.7包？这一步看是在浪费几分钟，实际上能帮你省掉后面大把的折腾时间。

1.1 先确认系统版本和架构

在ARM服务器上最容易犯的错就是拿着x86时代的经验直接套，第一步先确认硬件架构和系统版本，命令很简单：

uname -m cat /etc/redhat-release

正常情况下，ARM64架构会输出aarch64，CentOS 7会输出类似CentOS Linux release 7.9.2009 (Core)这样的字样。

注意，ARM64还有个别名叫ARMv8-A，对应的市场宣传口号有的叫鲲鹏、飞腾、TX2之类。但在Linux层面，统一识别标志就是aarch64。如果你的uname输出是armv7l或者armhf，那是32位ARM，这篇的安装思路不完全适用，得另找方案。

1.2 为什么ARM64上装MySQL 5.7这么折腾

x86架构下安装MySQL 5.7可以说是“一条yum命令搞定的事”，前提是你先配置好MySQL官方yum源。但换到ARM64架构，情况就完全不同了。MySQL官方确实提供了ARM64平台的yum仓库，但仓库里的版本只有MySQL 8.0及以后版本，5.7的ARM64 RPM包从未发布过。

CentOS官方的base源里也搜不到mysql-community-server的5.7版本，默认源里只有MariaDB，而且MariaDB从版本号到内核都和MySQL 5.7不完全等同。如果你的应用用了MySQL 5.7特定的语法、存储过程或者某些引擎特性，直接切到MariaDB是有风险的。我曾经在某项目里遇到过一个问题，业务代码用了MySQL 5.7的JSON函数，在MariaDB上行为不一致，最后排查了很久才发现是数据库版本替换导致的。

所以ARM64 + CentOS 7 + MySQL 5.7，这三个条件叠加在一起，基本就是逼着你走源码编译这条路了。

1.3 方案对比：为什么源码编译是最终答案

当时我列了四个候选方案：

1. MySQL官方yum源安装MySQL 8.0：如果能接受大版本升级，这是最省事的路。但业务不让动大版本，直接排除。
2. 用Docker跑MySQL 5.7镜像：确实有ARM64移植版的镜像，起码是能用的。但生产环境不一定会给你装Docker的权限，而且性能损耗、存储卷管理、容器网络这些也都是额外的运维负担。在有几台物理服务器要部署的场景下，镜像方式还是不够“原生”。
3. 用MariaDB替代MySQL 5.7：兼容性不是100%。
4. 源码编译MySQL 5.7：需要自己搞定编译工具链，过程长、依赖多，但产物是最纯粹的、最贴合本机环境的，而且一旦编译成功，后续批量部署就是复制粘贴的事情。

最终我选择了源码编译。这篇文章后面所有的内容都是在这个方案下展开。

2. 编译依赖与工具链准备

源码编译MySQL 5.7需要一整套完整的开发和构建工具链，而且在ARM64架构下，工具链的取舍尤其关键，因为不同工具链编译出来的二进制在运行时会有兼容性差异。

2.1 安装基础编译工具

CentOS 7默认是不带gcc的，但在最小化安装下通常得有基础开发包。直接敲下面这条命令把工具链一次性补齐：

yum install -y gcc gcc-c++ make cmake bison ncurses-devel libaio-devel

逐个解释一下：

• gcc和gcc-c++是编译C和C++代码的核心编译器。
• make是编译调度工具。
• cmake是MySQL 5.7使用的构建系统生成器，不是用autotools那套。
• bison是语法分析器生成器，MySQL在编译过程中需要用到。
• ncurses-devel提供终端交互所需的基础库，否则编译时会报缺头文件。
• libaio-devel是MySQL处理异步I/O时的依赖库。

还有一个很容易漏掉的包：openssl-devel。虽然MySQL可以编译成使用bundle的SSL库，但我习惯用系统的OpenSSL来减少重复链接问题。建议顺手装一下：

yum install -y openssl-devel

另外，如果系统之前装过老版本MySQL或者MariaDB，先清理干净，否则后面初始化数据目录时会碰到端口、socket文件冲突。检查方法很简单：

rpm -qa | grep -E 'mysql|mariadb'

如果输出为空，说明没有残留，可以放心装。

2.2 ARM64架构下的编译器选择

这里要特别提醒一个容易被忽略的点。CentOS 7自带的gcc版本是4.8.5，年代确实久远，但编译MySQL 5.7完全够用。我自己第一次编译时，想着“老编译器会不会有问题”，于是用了devtoolset-7里的新版本gcc，结果编译出来的二进制在另一台只有默认gcc运行库的ARM机器上直接报GLIBC版本找不到的错误。

这就是最典型的编译器版本和系统运行库不匹配的问题。新gcc编译产物默认会链接到更高的GNU C标准库版本，CentOS 7默认的glibc版本是2.17，而新gcc编译出来的东西动不动就要求GLIBC_2.18甚至更新。如果只在本机跑，问题不大，但你要把编译产物复制到其他机器，那就处处碰壁。

所以我的建议是：能用系统自带gcc就用系统自带的，不要刻意追求高版本。MySQL 5.7的源码对编译器要求不高，gcc 4.8.5编译完全没问题。

另外，ARM64架构下还有一个和x86不一样的点：编译时需要指定一些与架构相关的优化参数。比如你可以给C编译器加上-march=armv8-a或者兼容性更好一点的-mtune=generic，用来保证编译出的二进制在所有ARM64机器上都能正常运行。CMake里可以通过设置CMAKE_C_FLAGS和CMAKE_CXX_FLAGS来传参。

2.3 用户与目录规划

源码编译安装的MySQL和yum安装的MySQL在目录结构上有差异，我建议从一开始就规划好，避免后面乱了。

我习惯采用这样的目录结构：

• 安装目录：/usr/local/mysql
• 数据目录：/data/mysql
• 日志目录：/var/log/mysql
• 运行目录：/var/run/mysql

创建MySQL专用的系统用户，注意是系统用户，不是普通登录用户：

groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql mkdir -p /data/mysql mkdir -p /var/log/mysql mkdir -p /var/run/mysql chown -R mysql:mysql /data/mysql chown -R mysql:mysql /var/log/mysql chown -R mysql:mysql /var/run/mysql

这一步看似普通，但有个细节很关键：/var/run/mysql的权限。很多人在启动MySQL时遇到“Can't create/write to file '/var/run/mysqld/mysqld.pid'”的错误，就是因为在初始化阶段没有给运行目录授权，或者目录根本不存在。

3. MySQL 5.7 源码编译实录

环境准备好以后，下面就是整个过程中耗时最长、最容易出问题的部分了。源码编译MySQL 5.7的完整流程可以拆成下载解压、CMake配置、make编译、安装四个环节。

3.1 下载源码包：选对版本是关键

MySQL官网提供的源码包有两种形式，一种是纯净源码包，一种是带boost库的源码包。这里强烈建议选择带boost的那一款，别节约那几MB流量。

为什么？因为MySQL 5.7的CMake配置强制要求指定WITH_BOOST参数，而且它对boost的版本极其挑剔。我试过用系统yum源里的boost-devel，结果版本不匹配，CMake直接退出。后来老老实实下载官方带boost的源码包，一把过。

cd /usr/local/src wget https://cdn.mysql.com/archives/mysql-5.7/mysql-boost-5.7.44.tar.gz tar -xzf mysql-boost-5.7.44.tar.gz cd mysql-5.7.44

具体的下载链接可能会因为版本存档调整而变动，可以去官网archives目录里找到对应的带boost包。

3.2 CMake配置参数逐个拆解

进入源码目录后，创建独立的编译目录是一个好习惯。可以避免源码目录被编译产物污染，以后想重新编译时直接删掉build目录就行。

mkdir -p build && cd build

然后执行cmake配置。下面是我最终使用的参数，每个参数都值得解释：

cmake .. \ -DCMAKE_INSTALL_PREFIX=/usr/local/mysql \ -DMYSQL_DATADIR=/data/mysql \ -DSYSCONFDIR=/etc \ -DWITH_BOOST=../boost \ -DDEFAULT_CHARSET=utf8mb4 \ -DDEFAULT_COLLATION=utf8mb4_general_ci \ -DWITH_EXTRA_CHARSETS=all \ -DWITH_SSL=system \ -DENABLED_LOCAL_INFILE=1 \ -DWITH_DEBUG=0 \ -DCMAKE_C_FLAGS="-march=armv8-a -O2"

逐项说明：

• CMAKE_INSTALL_PREFIX：安装根目录，所有二进制文件都会装到这里。
• MYSQL_DATADIR：数据目录，后面初始化时要用到。
• SYSCONFDIR：配置文件目录，这里指定为/etc，这样MySQL会读取/etc/my.cnf。
• WITH_BOOST：boost源码路径，因为我们下载的是带boost的包，所以直接指向../boost。
• DEFAULT_CHARSET和DEFAULT_COLLATION：默认字符集和排序规则。这里选用utf8mb4而不是老旧的utf8，因为utf8在MySQL里实际是utf8mb3，只能存基本多语言平面字符，遇到emoji或者生僻字就乱码。
• WITH_EXTRA_CHARSETS=all：把其他字符集也编进去，方便以后切换。
• WITH_SSL=system：使用系统OpenSSL库，避免内置SSL库可能存在的兼容问题。
• ENABLED_LOCAL_INFILE=1：允许LOAD DATA LOCAL INFILE导入本地文件，这个对数据处理场景很有用。
• WITH_DEBUG=0：明确不编译debug版本，减小二进制体积。
• CMAKE_C_FLAGS：ARM架构优化参数。这里的-march=armv8-a表示针对ARM v8-A架构生成优化代码。不过有一点要注意，如果编译出的二进制要拷贝到别的ARM服务器，最好用-march=armv8-a而不是更具体的cortex-a72这种针对特定CPU的march，否则换台机器可能就跑不起来了。

这里还有个小坑，就是CXX的标记。MySQL在编译过程中有大量C++代码，所以还建议同时设置：

-DCMAKE_CXX_FLAGS="-march=armv8-a -O2"

如果不在CMAKE_CXX_FLAGS中指定-march，C++部分可能会沿用默认通用架构，导致C和C++部分的优化不一致，虽然不影响功能，但性能上差那么一点意思。

3.3 make编译：耐心和内存的双重考验

配置完成、没有报错后，就可以开始正式编译了。这一步是最磨人的，尤其是ARM服务器如果内存不高，非常容易在编译过程中把C++编译器进程挤崩。

make -j4

-j参数决定了同时开启几个编译任务。我个人的建议是：如果服务器内存大于8GB，-j4没问题；内存只有4GB，-j2更稳妥。有人会觉得-j8能更快，但一旦触发内存不足导致编译进程被内核杀掉，前面十几分钟的进度就全白费了。

整个编译过程大概需要20到40分钟，取决于机器性能。期间控制台会刷出大量警告和进度，不用太紧张。如果看到error字样，才需要停下来看。常见的一个错误是“internal compiler error: Killed”，这是内存不足的典型信号。这时候降低并行数，或者临时扩一下swap再来。

[wait，我需要在文章中展示一些实际编译输出效果的描述，但又不能使用代码块放太长的编译日志，那样会占篇幅。我可以在描述中说“最明显的特征就是屏幕滚动速度极快，最后生成一堆.o结尾的目标文件”]

编译完成后执行安装：

make install

这一步速度很快，几秒钟就完成。安装完成后检查一下/usr/local/mysql/bin目录下是否出现了mysqld、mysql、mysqladmin等可执行文件。

3.4 ARM环境特有的编译优化与验证

编译完成后有一个容易被跳过但非常关键的验证步骤：确认二进制文件确实是ARM64格式，以及动态库依赖是否完整。

file /usr/local/mysql/bin/mysqld

输出应该是ELF 64-bit LSB executable, ARM aarch64这样的字样。然后查看动态库依赖：

ldd /usr/local/mysql/bin/mysqld

如果输出中所有依赖都能找到对应的.so路径，说明二进制是完整的。如果出现“not found”的条目，就需要回头补装对应devel包并重新编译相关模块。

这个验证动作很重要，因为在ARM64环境下，缺库不是你主观能判断出来的，只有ldd才会暴露出底层的动态链接问题。

4. 初始化数据目录与服务配置

编译安装完成只是万里长征第一步，后面配置MySQL的运行环境和系统服务才是让数据库真正能干活的关键。

4.1 编写my.cnf配置文件

源码编译安装的MySQL默认不一定能找到配置文件，即使你指定了SYSCONFDIR，也需要主动创建一个/etc/my.cnf。我的配置如下，可以作为参考：

[mysqld] basedir=/usr/local/mysql datadir=/data/mysql socket=/var/run/mysql/mysql.sock pid-file=/var/run/mysql/mysqld.pid log-error=/var/log/mysql/mysqld.log port=3306 server-id=1 character-set-server=utf8mb4 collation-server=utf8mb4_general_ci max_connections=500 max_connect_errors=1000 innodb_buffer_pool_size=1G innodb_log_file_size=256M innodb_flush_log_at_trx_commit=1 sync_binlog=1 skip-name-resolve

这里有几个参数要特别说明。

socket和pid-file的路径，必须和之前创建的运行目录一致。如果不写socket，客户端默认会去/tmp/mysql.sock找，那和这里定义的位置就对不上了。

skip-name-resolve这个参数，建议在非必须域名反解的环境下开启。它可以让MySQL不进行反向DNS解析，大幅提升连接速度。如果你的客户端使用IP地址连接数据库，开这个参数没有副作用；但如果用的是主机名连接，就需要想清楚，因为开启后主机名会解析失败。

innodb_flush_log_at_trx_commit=1和sync_binlog=1是保证数据持久性的关键参数，如果你是生产环境，千万不要为了追求性能把这两个参数改成0或2，否则一旦机器断电，可能丢数据。

另外，如果你的机器内存只有4GB，innodb_buffer_pool_size建议改成512M，不然MySQL启动加系统本身就可能吃满内存。

4.2 初始化数据目录

MySQL 5.7以前可以用mysql_install_db初始化数据目录，但从5.7开始，官方推荐用mysqld自带的--initialize参数。

需要先确保数据目录是空的，如果之前编译时测试过什么，里面可能有残留，清干净再执行：

rm -rf /data/mysql/* /usr/local/mysql/bin/mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql

这里用--initialize-insecure而不是--initialize，两者差异在于：--initialize会生成一个随机临时密码，并且密码会被输出到错误日志；--initialize-insecure则会把root密码初始化为空。

对于测试环境或者需要自动化部署的场景，我推荐用--initialize-insecure，因为临时密码确实容易弄丢。但要注意，用这个模式初始化后，root账户是没有任何密码的，必须马上修改，否则就等于把数据库裸奔在网络上。

初始化成功后，数据目录下会出现一堆文件和目录，其中有一个以你的主机名命名的.err日志文件，如果出问题，先看这个文件。

4.3 配置systemd服务与开机自启

MySQL源码包自带一个脚本：/usr/local/mysql/support-files/mysql.server。可以把这段脚本注册为systemd服务，也可以直接写一个unit文件。我更推荐直接写unit文件，这样更可控、更透明。

创建一个/etc/systemd/system/mysqld.service文件，内容如下：

[Unit] Description=MySQL Server 5.7 After=network.target [Service] Type=forking User=mysql Group=mysql PIDFile=/var/run/mysql/mysqld.pid ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --daemonize ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure PrivateTmp=false [Install] WantedBy=multi-user.target

别小看这个unit文件，里面每一行都有讲究。

Type必须是forking，因为mysqld启动时会派生出一个守护进程，父进程退出，子进程继续运行，这正好对应forking类型。

PIDFile的值必须和my.cnf里配置的pid-file路径完全一致，否则systemd无法准确判断服务状态，甚至可能出现“服务已经启动但systemd还显示active (exited)”的诡异现象。

PrivateTmp=false这一行容易被忽略。systemd默认可能会启用私有/tmp隔离，某些版本下会导致MySQL的临时文件访问异常，显式关掉可以少踩一个坑。

写完后，刷新systemd并启动服务：

systemctl daemon-reload systemctl enable mysqld systemctl start mysqld

启动后立即查看状态：

systemctl status mysqld

如果是active (running)，恭喜你，数据库已经跑起来了。但别高兴太早，许多问题会在你第一次连接时暴露。

5. 安全加固与基础功能验证

MySQL能启动，说明系统层面的安装已经成功，接下来就是数据库内部的安全设置和功能验证。这一部分很多人会草草带过，但恰恰是一些小疏忽，导致后面业务连接时出各种幺蛾子。

5.1 修改root密码

用--initialize-insecure初始化后，root账户密码为空，用以下命令就能登录：

/usr/local/mysql/bin/mysql -uroot -p

会提示输入密码，直接回车就能进。进去后第一件事就是改密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码'; FLUSH PRIVILEGES;

如果你对rpm方式安装MySQL比较熟，可能习惯用SET PASSWORD = PASSWORD('xxx')，但在MySQL 5.7里ALTER USER同样支持，推荐用ALTER USER，语法更规范。

5.2 创建业务账户与远程访问控制

生产环境里，root账户一般只留给本地维护，业务方需要的是一个权限受控的专用账号。假设要创建一个名叫app_user的账号，允许从任意IP连接，密码是App@123456：

CREATE USER 'app_user'@'%' IDENTIFIED BY 'App@123456'; GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'%'; FLUSH PRIVILEGES;

这里有个安全细节想多说一句。GRANT ALL PRIVILEGES ON app_db.*已经能解决90%的场景，没必要给app_user授予全局权限。有些项目为了省事直接GRANT ALL PRIVILEGES ON.，一旦数据库被攻破，整个实例的所有库都会沦陷。权限最小化在数据库侧同样是铁律。

如果业务要求只能从特定网段连接，比如10.10.10.0/24网段，建议创建用户时这样指定：

CREATE USER 'app_user'@'10.10.10.%' IDENTIFIED BY 'App@123456';

这样做的效果是：来自其他IP的连接直接报Access denied，比在应用层做ACL更可靠。

5.3 字符集与基本读写验证

远程账号创建完成后，验证一下基本读写能力。先查看字符集配置是否生效：

SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server';

这两个值应该是utf8mb4和utf8mb4_general_ci，和my.cnf中的配置一致。

接着建一个测试库和测试表：

CREATE DATABASE IF NOT EXISTS app_db DEFAULT CHARACTER SET utf8mb4; USE app_db; CREATE TABLE test_conn ( id INT AUTO_INCREMENT PRIMARY KEY, note VARCHAR(100) ); INSERT INTO test_conn(note) VALUES('hello arm64 mysql'); SELECT * FROM test_conn;

如果一切正常，查询会返回刚才插入的那条数据。到这里，数据库的新增、查询功能就验证通过了。

接下来还需要确认MySQL的监听地址。默认情况下，MySQL会监听所有网卡，但如果你在my.cnf里写了bind-address=127.0.0.1，那远程连接永远连不上，而连接报错还特别容易让人误以为是防火墙问题。

检查监听地址：

netstat -tlnp | grep 3306

如果看到0.0.0.0:3306或:::3306，说明监听正常。

如果网络层面没问题但仍然连不上，就要检查防火墙了。CentOS 7默认启用firewalld，需要在防火墙里放行MySQL端口：

firewall-cmd --permanent --add-port=3306/tcp firewall-cmd --reload

6. 问题排查与实战避坑清单

源码编译MySQL 5.7在ARM64机器上，整个流程走下来的确不是一帆风顺。我在这个过程中踩了不少坑，下面把遇到的高频问题和对应的排查思路整理出来，你可以直接对照自己遇到的情况。

6.1 高频编译与安装错误

错误一：CMake报错找不到Boost库

现象：

CMake Error at cmake/boost.cmake:81 (MESSAGE): Looked for boost in ...

原因：没有指定WITH_BOOST参数，或者指定的boost版本不匹配。

解决：使用带boost的源码包，并在cmake命令中加上-DWITH_BOOST=../boost（视具体目录结构而定）。

错误二：make阶段报错internal compiler error: Killed

现象：编译过程中突然出现大量类似“cc1plus: internal compiler error: Killed”的信息。

原因：内存不足，编译器进程被内核OOM Killer杀掉。在低配ARM服务器上尤其常见，因为编译MySQL需要大量内存。

解决：降低make并行数，比如make -j2；或者临时增加swap空间。

错误三：初始化时报找不到共享库

现象：

/usr/local/mysql/bin/mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file

原因：缺少libaio运行库，之前只装了devel包但运行时依赖没跟上。

解决：yum install -y libaio。

6.2 ARM环境特有的运行期问题

问题一：启动MySQL时报权限错误

现象：启动后日志里反复出现“Permission denied”之类的信息，基本功能无法进行。

原因：CentOS 7默认开启SELinux，MySQL的数据目录、socket目录都被SELinux保护，即使文件owner是mysql也无法读写。

解决：最简单的做法是把SELinux设为permissive模式：

setenforce 0

如果想一劳永逸，编辑/etc/selinux/config，把SELINUX=enforcing改成SELINUX=permissive。但如果你的公司有严格的安全基线要求，更好的做法是给MySQL的相关目录设置SELinux策略标签，而不是直接关SELinux。可以用以下命令查看一下当前上下文：

ls -Z /data/mysql

问题二：新编译的二进制文件在其他机器上跑不起来

现象：把编译产物打包到另一台同架构ARM服务器上，运行mysqld时报：

/lib64/libc.so.6: version `GLIBC_2.18' not found

原因：编译时用了新版gcc，二进制对glibc版本的要求超出了目标系统自带版本。

解决：编译时使用系统默认gcc；如果一定要用新版gcc，要关注glibc最低版本要求，并在相同或相近的系统环境下编译。

问题三：远程连接超时或拒绝连接

排查顺序是：

1. 本机能不能连：mysql -uroot -p
2. 监听地址对不对：netstat -tlnp
3. 防火墙放行没有：firewall-cmd --list-all
4. 网络和安全组通不通

如果本机能连，远程不能，90%出在防火墙或安全组；远程能连但报Access denied，那就是账号权限问题。

6.3 快速排查速查表

这张表里的每个问题都是我在实际环境里遇到过的。如果你运气好没有踩过其中某些坑，恭喜你，但如果遇到了，至少知道该往哪个方向排查。

从整个流程来看，在ARM64架构的CentOS 7上源码编译MySQL 5.7，门槛主要集中在前面半小时的编译等待和配置细节上，真正跑通之后，后续维护和x86环境并没有太大区别。我个人实际用下来，最需要注意的就是两点：一是编译参数里的march不要针对特定CPU，二是SELinux对数据目录的隐形拦截。这两个问题如果不提前规避，后面排查起来都很劳神。另外一个经验是：编译完成的二进制务必保留一个压缩包，放在内部文件服务器上，下次相同架构的机器可以直接复用这份编译产物，省去重新编译的半小时。毕竟ARM64编译MySQL 5.7这件事，最值钱的就是这份绕开所有坑的二进制包。