企业官网建设流程全解析

简介：面向ARM64架构Linux环境的MySQL 5.7.32二进制安装包，专门解决树莓派、飞腾、鲲鹏等平台缺少官方预编译版本、自行搭建编译环境成本高且耗时长的问题，可支撑直接解压部署与后续运维。资源共14882个文件，包体约510MB；除大量test与result测试用例文件外，还包含opt/inc配置及头文件、cnf配置模板、so共享库、dat数据文件、frm表结构文件、pem安全证书和sql脚本等，目录沿用官方源码树结构，便于检索、裁剪与二次开发。MySQL 5.7.32的InnoDB存储引擎、Performance Schema监控、JSON数据类型、查询优化器以及认证安全机制均有增强，配合glibc-2.28在主流ARM64系统上具备良好稳定性与性能表现，内置测试套件也有助于功能验证和问题排查。平台显示已有1416人学习下载，适合数据库运维、ARM平台研发及需要离线交付数据库服务的团队使用，能大幅缩短编译验证周期，也可作为深入理解MySQL目录结构和运行机制的参考。 手上有这么一包mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz的时候，很多人第一反应是直接解压安装，结果折腾半天起不来，报错一堆。这几年国产化进程加快，ARM 架构的服务器越来越常见，MySQL 的 aarch64 版本成了刚需，但这个文件名里其实藏着不少信息，读懂了才能少踩坑。

这篇文章就从这个压缩包入手，带你把“一个 tar.gz 变成一台能跑的 MySQL 实例”这件事完整过一遍。包括文件名解读、环境审查、二进制部署、初始化配置、systemd 托管和日常运维避坑，适合刚接触 Linux 下 MySQL 部署的运维新人，也适合给正在做 ARM 迁移的老手做个参考。内容都是实操经验，不是文档搬运，尤其里面的坑，基本是网上教程不会明说的。

1. 文件名里的信息量：先看懂再动手

1.1 每一段字符都在说什么

mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz这个文件名，拆开看是这样的：

• mysql-5.7.32：MySQL 版本号，5.7 是当前生产环境保有量最大的版本之一，5.7.32 属于 5.7 系列中期的稳定小版本，官方已停止维护，但大量存量项目还在用。
• linux：目标操作系统为 Linux。
• glibc-2.28：要求系统 glibc 版本不低于 2.28。glibc 是 Linux 下最基础的 C 运行库，MySQL 二进制包编译时链接了特定版本，运行时需要向下兼容。
• aarch64：ARM 64 位架构，对应uname -m输出里的 aarch64。注意它不是 x86_64。
• tar.gz：gzip 压缩的 tar 归档，没有任何安装程序，解压即用，属于“绿色版”。

这一段里面，最容易踩坑的是 glibc 版本。很多人在 CentOS 7.6、7.7 上装这个包，cat /etc/redhat-release看着没问题，但ldd --version一查 glibc 是 2.17，直接低于要求的 2.28，后面mysqld --initialize必报错。所以拿到包第一步不是解压，而是先验证环境到底能不能用。

1.2 为什么要用官方“通用二进制包”

MySQL 的安装方式有源码编译、RPM、Deb 包、Docker 镜像和这种通用二进制包。源码编译最灵活但最费时，RPM/Deb 包和发行版绑定太死，Docker 可以一键起但很多传统环境不支持或不想引入容器。通用二进制包是“免安装版”，解压改配置就能跑，依赖少，适合批量复制到多台机器，做版本固定和离线部署尤其方便。

这个包还有一个关键词“glibc-2.28”。如果系统 glibc 更高，通常没问题；如果更低，要么换系统，要么换低版本的 MySQL 包，要么老老实实走源码编译。不要尝试去升级系统 glibc，那是把整台机器往火坑里推，系统底层库一换，连 ls、cat 都可能挂。

2. 环境准备：动手前先做三件小事

2.1 确认架构和 glibc 真的达标

很多人在uname -m输出aarch64之后就以为万事大吉，其实还要再看一眼 glibc。两个命令必须执行：

uname -m # 输出应为 aarch64 或 arm64 ldd --version # 第一行会显示 glibc 版本，比如 2.28-11.el8 或 2.36-9

这里有个差异要提一下：有些国产系统（比如基于 openEuler 或统信 UOS 的发行版）虽然架构是 aarch64，但 glibc 版本较新，通常满足 2.28 要求。CentOS 7 的 ARM 版只有 GLIBC 2.17，就不要指望装这个包了。可以用下面这条命令精确检查动态库依赖是否满足：

ldd mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz 2>/dev/null # 或者解压后检查 bin/mysqld

更实际的做法是解压后直接看lib/mysqld的依赖，如果输出里出现libc.so.6 => not found，那就是 glibc 版本不够。还有一种情况是 libaio 缺失，这个不归 glibc 管，但同样会导致初始化直接失败。

2.2 创建用户和规划目录

MySQL 官方要求不要用 root 跑实例，生产环境也必须遵守。先建专用用户和目录：

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

安装目录我习惯放在/usr/local/mysql，数据目录独立放在/data/mysql/data。安装目录和数据目录分离是运维的基本原则：系统盘坏了重装不影响数据盘，备份和扩容也更灵活。顺便把/data所在的磁盘空间查一下，df -h /data，数据目录至少预留实际数据量的两倍，别等撑爆了才想起扩容。

提示：-s /sbin/nologin是为了让 mysql 用户无法登录 Shell，这是安全基线要求。测试环境无所谓，生产环境一定要加。

2.3 确认基础依赖已安装

aarch64 平台下有些依赖是必须的，少了任何一个，后面都会报各种奇怪错误：

# CentOS/RHEL 系 yum install -y libaio numactl-libs # Debian/Ubuntu 系 apt install -y libaio1 libnuma1 tar

libaio 是异步 IO 库，MySQL 的 InnoDB 存储引擎默认会调用，没有它mysqld --initialize会报error while loading shared libraries: libaio.so.1: cannot open shared object file。numactl-libs 在 NUMA 架构下用得到，ARM 服务器不少是多路，建议一起装。tar 命令不用说了，解压都靠它。这些依赖装上不会额外引入太大开销，但能避开后面很多幺蛾子。

3. 核心实操：从压缩包到可用数据库

3.1 解压、改名、建软链

先把包传到目标机器上，建议放到/usr/local/src再解压到/usr/local，不要直接在数据盘解压。整个流程如下：

cd /usr/local/src tar -xf mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz -C /usr/local/ cd /usr/local mv mysql-5.7.32-linux-glibc-2.28-aarch64 mysql ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql ln -s /usr/local/mysql/bin/mysqldump /usr/local/bin/mysqldump ln -s /usr/local/mysql/bin/mysqld /usr/local/bin/mysqld

软链这一步很多人忽略，后面敲mysql -uroot -p直接command not found。其实不建软链也能干活，每次全路径/usr/local/mysql/bin/mysql执行就行，但没人愿意一直敲这么长的路径。建软链后顺手再配一下 PATH 更稳妥，编辑/etc/profile.d/mysql.sh：

export PATH=$PATH:/usr/local/mysql/bin

然后source /etc/profile.d/mysql.sh或重新登录。装完我一般习惯用ls -l /usr/local/mysql确认软链指对了，再用/usr/local/mysql/bin/mysqld --version验证目录权限和二进制可执行。

3.2 初始化数据目录：两个参数差别很大

初始化是部署过程中最容易翻车的一步。5.7 版本用mysqld --initialize，但有个小岔路要先说清楚：

• --initialize：生成一个随机临时 root 密码，日志里输出。
• --initialize-insecure：root 账号无密码，可以直接空密码登录。

我自己的习惯是测试环境用--initialize-insecure，省得还要去日志里翻临时密码，生产环境则用--initialize，严格走密码生成流程。执行初始化前要先把配置文件准备好，否则它会用默认配置，之后路径可能和预期不符。

先创建一个最小可用的配置文件/etc/my.cnf：

[mysqld] basedir=/usr/local/mysql datadir=/data/mysql/data socket=/tmp/mysql.sock pid-file=/tmp/mysql.pid port=3306 log-error=/data/mysql/logs/mysql-error.log character-set-server=utf8mb4 collation-server=utf8mb4_general_ci user=mysql

注意log-error的目录需要先存在，最好同时建好：

mkdir -p /data/mysql/logs chown -R mysql:mysql /data/mysql

然后执行初始化：

/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --initialize-insecure

如果看到输出空空如也、没有报错，就是成功了。用--initialize的话，临时密码会写在 error log 里：

tail -20 /data/mysql/logs/mysql-error.log # 找到类似这样的行： # [Note] A temporary password is generated for root@localhost: xxxxxxxx

注意：初始化时--defaults-file必须放在最前面，放在后面会导致 MySQL 不识别，这是一个常见的低级错误。另外配置文件里的user=mysql也很关键，如果漏了，mysqld 会以 root 身份运行并告警，虽然能跑但不建议。

3.3 目录属主和权限不能马虎

初始化完成后，立刻复查数据目录的属主：

chown -R mysql:mysql /data/mysql /usr/local/mysql

这一步必须做，否则启动时mysqld_safe会报权限问题。还要注意/tmp目录不能是 noexec 挂载，MySQL 会在/tmp下创建 socket 和临时表文件，如果/tmp是 noexec，启动会异常。这个坑在等保加固后的服务器上很常见，一般排查方式是用mount | grep /tmp看一眼挂载参数。

3.4 首次启动和登录验证

执行启动时，用mysqld_safe还是直接用mysqld？我建议先用前台方式验证配置没问题：

/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf &

或者用官方推荐的mysqld_safe（5.7 自带）：

/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &

启动后检查端口和进程：

ps -ef | grep mysqld ss -lntp | grep 3306

看到 3306 LISTEN 就说明起来了。如果起不来，tail -f /data/mysql/logs/mysql-error.log看最后的报错。登录测试：

# 如果是 --initialize-insecure mysql -uroot -p # 如果是 --initialize，用日志里的临时密码登录，然后立即改密 ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourStrongPassword';

测试环境我给的建议是设置一个强密码先让它跑起来，生产环境下一步必须走安全加固脚本，这个后面第五节讲。

4. 启动验证与常见问题排查

4.1 常见报错速查表

这一节直接把我在 aarch64 环境中实际遇到的报错整理成表，比一个个看日志高效多了。

这张表里第一个和第二个是最常见的。第三个Can't find error-message file很多人会忽略，它不影响启动，但客户端报错时看不到中文或正常的错误提示，排查问题难度直接翻倍，根源基本是basedir指定错误或 share 目录缺失。

4.2 初始化报错的排查思路

初始化失败时，不要反复原地重跑，先查日志，再确认环境。举个例子，第一次初始化报 InnoDB 的错误，可能是/data/mysql/data下残留了半成品文件，这时候必须清空数据目录再重新初始化，否则反复报错。清理命令要小心：

rm -rf /data/mysql/data/*

数据目录如果已有业务数据，这个操作是灾难性的，所以生产环境执行前一定确认这是新部署的机器。初始化不成功的另一个常见原因是磁盘空间不足，df -h /data看一下，InnoDB 初始化需要写 redo 和 system tablespace，空间不够会直接静默失败。

另外要说一下，aarch64 架构下偶尔能遇到 glibc 2.28 版本“高于”所需但仍然报错的情况，这通常是系统里存在多个 glibc 环境，比如 conda、python 虚拟环境自带的 libc 覆盖了系统路径。这类问题比较隐蔽，判断方法是LD_LIBRARY_PATH是否被污染，执行echo $LD_LIBRARY_PATH，如果有非常规路径，临时清空再启动：

unset LD_LIBRARY_PATH /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &

5. 让它稳定跑起来：systemd 管理与安全建议

5.1 用 systemd 管理而不是裸进程

mysqld_safe 方式适合临时排查问题，但重启机器后不能自动拉起，还是建议用 systemd 托管。创建/etc/systemd/system/mysqld.service：

[Unit] Description=MySQL Server 5.7.32 After=network.target [Service] Type=notify User=mysql Group=mysql ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf LimitNOFILE=65535 Restart=on-failure TimeoutSec=300 [Install] WantedBy=multi-user.target

注意Type=notify是 5.7 版本推荐的启动类型，它会让 systemd 等待 mysqld 自己发出 ready 通知，避免出现“服务显示启动成功但实际还没就绪”的误判。写好后：

systemctl daemon-reload systemctl enable mysqld systemctl start mysqld systemctl status mysqld

如果ExecStart直接启动失败，先看journalctl -u mysqld -n 50，确认 error log 里有没有相关内容。Restart=on-failure保证了 mysqld 崩溃后自动拉起，对线上稳定性很有帮助，LimitNOFILE也要给足，不然高并发下连接数一多，Too many open files就来了。

5.2 安全加固脚本和新密码策略

5.7 自带一个安全加固脚本，强烈建议装完就跑：

/usr/local/mysql/bin/mysql_secure_installation

按提示做几件事：设置 root 密码、删除匿名用户、禁止 root 远程登录、删除 test 数据库、刷新权限表。生产环境这几项全部选是，测试环境至少把匿名用户和 test 库删掉。

还有几点是我实际踩过的：

• 不要把 root 暴露给外部 IP 连接。应用账号要单独创建，例如CREATE USER 'app'@'10.0.0.%' IDENTIFIED BY 'StrongPass';，然后按最小权限GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'app'@'10.0.0.%';。
• skip_name_resolve建议开启，关闭反查 DNS 可以减少连接延迟，但开启后必须使用 IP 授权，不能使用 hostname 授权。
• 修改bind-address，测试环境可以注释掉或0.0.0.0，生产环境只监听内网 IP，bind-address=10.0.0.10这种写法。

提示：安全加固脚本执行后 root 密码会改变，所有已建立的应用连接会全部断开，属于正常现象。部署时建议选业务低峰期。

5.3 备份习惯和数据目录规划

数据库跑起来之后，第一件事不是做功能测试，而是先配备份。5.7 可以用mysqldump，也可以直接用物理备份工具xtrabackup。小数据量场景直接用mysqldump每天定时全量备一次就够了，核心命令如下：

/usr/local/mysql/bin/mysqldump -uroot -p --single-transaction --master-data=2 --all-databases > /backup/mysql_$(date +%F).sql

--single-transaction保证 InnoDB 备份期间数据一致性，不会锁死业务；--master-data=2会在备份文件里记录 binlog 位置，后面要做从库或恢复时非常有用。备份文件最好放到独立磁盘，别跟数据目录同盘，否则磁盘一起坏就全没了。

数据目录这块多说一句：/data/mysql/data和 binlog 目录最好分开。可以在 my.cnf 里单独指定：

log-bin=/data/mysql/binlog/mysql-bin expire_logs_days=7 max_binlog_size=512M

binlog 独立目录的好处是，备份时可以单独对数据目录做快照，日志文件不会被一次性清掉。expire_logs_days=7控制只保留 7 天日志，避免 binlog 把磁盘写满，这个参数在 5.7 里是expire_logs_days，8.0 之后换成了binlog_expire_logs_seconds，用 5.7 的同学别混淆。

5.4 资源限制和内核参数微调

跑 MySQL 的机器，建议顺手把内核参数和资源限制调一下。编辑/etc/security/limits.conf，追加：

mysql soft nofile 65535 mysql hard nofile 65535 mysql soft nproc 65535 mysql hard nproc 65535

同时在/etc/sysctl.conf里追加：

net.core.somaxconn = 65535 vm.swappiness = 10

vm.swappiness设为 10 是降低 swap 的使用倾向，让 MySQL 尽量用内存，尤其 5.7 的 InnoDB buffer pool 很吃内存，频繁 swap 会导致性能断崖式下跌。net.core.somaxconn调大是为了应对短连接风暴，Linux 默认 128，在高并发连接场景下很容易成为瓶颈。执行sysctl -p使其生效。这些都是常规调优，如果只是搭个测试库可以不做，但生产环境千万别省。

6. 个人经验：几个让我印象深刻的事

这次部署 5.7.32 aarch64 包，最大的教训就是“别急着解压，先看文件名的每一段”。很多同事一拿到包就tar -xf，然后初始化报错，才想起来查 glibc 版本，一来一回浪费半小时。我自己现在养成的习惯是：任何二进制包到手，第一步ldd --version，第二步uname -m，第三步查file确认架构：

file mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz

这个file命令会输出压缩包类型和字节序信息，如果目标机器是 x86_64，运行 aarch64 包会直接Exec format error，这是架构不匹配最直观的信号。

还有一个小技巧是，不管用什么方式部署，我始终保留一份my.cnf的备份，放在/etc/my.cnf.bak.$(date +%F)。改配置前先备份，出了问题 3 秒钟回滚，这个习惯救过我很多次。数据库这种东西，慢是小事，挂才是大事，所有操作都留一条退路，永远没错。

本文还有配套的精品资源，点击获取