简介这是专为64位ARM架构AArch64/ARM64编译的MySQL 5.7.32 Linux安装包面向需要在树莓派4、ARM服务器等设备上部署数据库的开发者与运维人员解决通用Linux包无法在arm平台直接运行的问题。安装包内含14882个文件除MySQL核心二进制外还包括大量test/result测试用例与结果、opt/inc等配置与头文件、cnf配置文件、so动态库、data/frm数据库文件以及mysql_install_db、mysql_secure_installation等管理工具压缩包整体约510MB目录结构贴近官方发行版解压后即可获得可运行的MySQL二进制环境和完整测试集。目前已有1416人学习下载。基于该安装包读者可快速完成arm平台上的MySQL环境搭建、初始化和安全配置也可通过附带工具与测试用例进行功能验证和性能调优充分发挥ARM设备的性能潜力。 拿到mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz这个文件名的时候很多人第一反应是一个安装包的名字为什么能长成这样实际上这个文件名已经把需要确认的信息全部剧透了——版本是 5.7.32系统平台是 Linux依赖的 glibc 是 2.28CPU 架构是 aarch64打包格式是 tar.gz。我在 aarch64 服务器上装 MySQL 的次数两只手数不过来每次看到这类包名反而觉得安心因为通过这些信息可以提前判断当前机器能不能直接跑、还需要准备什么依赖、装完该怎么配。这篇文章就把这个包名拆开讲清楚然后带你把整个安装流程完整跑一遍包括环境检查、目录规划、配置初始化、服务启动以及我踩过的几个典型坑。1. 文件名里的信息量为什么每个字段都值得较真1.1 版本号 5.7.32 到底意味着什么MySQL 的版本号由三部分构成主版本号、副版本号、补丁版本号。5.7.32 属于 5.7 系列这个系列从 2015 年发布之后持续维护了很多年是很多生产环境至今仍在使用的版本。5.7 相比更早的 5.5/5.6最大的变化在于默认存储引擎是 InnoDBJSON 类型正式支持性能监控表 Performance Schema 大幅增强还引入了更安全默认配置、sql_mode 默认开启 ONLY_FULL_GROUP_BY 等机制。为什么 5.7.32 这个版本至今还有人专门去找一方面是因为很多老系统的官方源比如某些 Linux 发行版自带的仓库只带 5.5/5.7 的老版本另一方面是 5.7 的稳定性和兼容性经过了大量生产环境验证。如果你现在接触到一个业务系统要求“MySQL 5.7.32 且跑在 aarch64 上”大概率是适配新硬件平台、迁移业务系统或者复现一套基于固定版本的测试环境。这类场景不建议直接跳到 8.0因为行为差异确实不少比如密码认证插件、字符集默认值、授权方式都有变动。1.2 glibc 版本决定系统最低门槛glibc 是 GNU C Library是 Linux 系统中几乎所有用户态程序运行的基础动态链接库。程序在编译时链接了某个版本的 glibc运行时就需要系统提供不低于这个版本的 glibc。这里的关键在于 glibc 是向后兼容的高版本系统可以运行低版本编译的程序反过来则不行。用一个生活化的类比glibc 版本像翻译标准——高版本的翻译看得懂老文档老翻译看不懂新规范。glibc-2.28这个标记表示编译这个 MySQL 包时用的是 glibc 2.28 的工具链。这意味着目标系统的 glibc 版本必须大于等于 2.28否则启动时直接报 “GLIBC_2.28 not found”。这也就是为什么网上有不少人拿到新包后在 CentOS 7自带 glibc 2.17上提示依赖缺失、根本无法运行的原因。遇到这种情况不需要慌张解决思路有两条要么给系统升 glibc风险非常高我下面会专门讲要么下载一个基于更低 glibc 编译的 MySQL 版本。这里有一个实操建议如果装了系统之后发现 glibc 过低手动升级 glibc 是运维中最容易翻车的操作之一因为 glibc 是几乎所有命令和服务的运行基础升级失败甚至可能导致系统直接无法启动。生产环境中务必谨慎最好优先考虑匹配系统版本的安装包。1.3 aarch64 与 tar.gz 的解读aarch64是 ARM 64 位架构的标准名字常见于 ARMv8 以上的处理器。国内常见的鲲鹏、飞腾、以及很多服务器级的 ARM 芯片都属于这个架构。之所以在文件名里显式标出是因为 MySQL 官方对不同架构发布不同的二进制包x86_64 的包没法直接在 aarch64 上跑底层指令集不一样。如果你的uname -m输出是aarch64那这个包就是正主如果输出是armv7l32 位 ARM或者x86_64那就得重新找对应版本。tar.gz 是 Linux 下最通用的源码/二进制打包格式实际过程是先通过 tar 打包再用 gzip 压缩。解压命令对应tar -xf新版 tar 能自动识别压缩格式为了保险也可以写成tar -zxvf显式指定。这个格式本身是纯文本的打包结果解压后即可看到完整的目录结构。2. 动手前必做的三件事架构确认、依赖检查、方案选型2.1 快速确认目标机器架构安装之前先花十秒钟确认机器架构和当前系统的 glibc 版本避免装到一半才发现不匹配。我最常用的三条命令如下每一条都有不同的用途# 查看 CPU 架构 uname -m # 查看 glibc 版本输出第一行最后一个字段 ldd --version # 查看操作系统发行版 cat /etc/os-release如果uname -m输出aarch64说明架构匹配可以直接用这个包。ldd --version的完整输出类似ldd (GNU libc) 2.31只要数字大于等于 2.28 就满足要求。cat /etc/os-release可以帮你判断当前系统是哪个发行版这决定了后面用 yum 还是 apt 安装依赖包。这里补充一个容易被忽略的细节有些嵌入式设备或边缘网关看起来是 Linux但内核和系统裁剪得很厉害连 glibc 都不完整。遇到这种设备不要试图用通用 Linux 的 MySQL 二进制包要么用交叉编译方案要么改用容器。最简单粗暴的判断方式就是执行ldd --version如果命令本身都跑不出来说明系统基础库不全后续几乎没有可能直接跑起来。2.2 确认 glibc 版本与依赖库的边界glibc 版本只是第一道门槛实际启动 mysqld 时还会检查其他动态库。最常见的是libaioMySQL 的 InnoDB 引擎在 Linux 上需要用到异步 I/O 接口 libaio。没有安装的话启动时报错信息相当直白“error while loading shared libraries: libaio.so.1: cannot open shared object file”。在 Debian/Ubuntu 上用apt-get install -y libaio1在 CentOS/RHEL 上用yum install -y libaio或者dnf install -y libaio就能解决。另外如果系统开启了 AppArmorUbuntu 默认开启或 SELinuxCentOS/RHEL 默认开启需要注意安全策略是否限制了 mysqld 对数据目录的读写。有时候数据目录权限明明配好了服务依然报错查到最后发现是 SELinux policy 拒绝了。临时放行的命令是setenforce 0仅限测试环境生产环境建议用semanage fcontext把数据目录加进白名单而不是粗暴关闭。2.3 二进制包安装 vs Docker 安装怎么选在 aarch64 服务器上部署 MySQL其实有两种主流路径直接使用官方二进制包也就是这篇文章的主角或者用 Docker 镜像。需要说明的是考虑到容器镜像的分发方式Docker 部署对 glibc 版本的敏感度相对更低但宿主机上的内核、以及容器运行环境本身也具备一定要求。二进制的安装方式更贴近传统运维习惯便于理解 MySQL 底层的运行机制、日志和目录结构也更容易做定制化调优。如果只是本地开发、快速起服务Docker 确实是省事的选择docker run -d --name mysql -e MYSQL_ROOT_PASSWORDxxx mysql:5.7一条命令就完成。但如果你的场景是生产环境、内网离线部署或者需要深度定制 MySQL 的配置那我还是推荐用官方二进制包。最核心的原因是二进制包与系统深度融合目录规划、参数文件和进程管理都完全掌握在运维手里出了问题能快速排查不像容器那样多一层隔离。另外离线环境下分发一个 tar.gz 文件远比导入一个 docker 镜像方便得多。注意如果是内网离线环境需要提前准备好 libaio、libncurses 等依赖包否则因为缺依赖导致 mysqld 无法启动排查起来十分痛苦。3. 完整安装实操从 tar.gz 到能稳定运行的 MySQL3.1 解压与目录规划先把所有需要的文件放到一个临时目录比如/opt/pkg然后执行解压cd /opt/pkg tar -xf mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz解压后会出现一个名为mysql-5.7.32-linux-glibc-2.28-aarch64的目录。为了方便管理我习惯把它移动到标准位置/usr/local/mysqlmv mysql-5.7.32-linux-glibc-2.28-aarch64 /usr/local/mysql这里有一个目录规划的心得不要把数据目录放在/usr/local/mysql/data生产环境建议单独规划一个数据目录比如/data/mysql。原因很实际系统盘一旦被日志或大文件写满整个系统都会出问题数据目录放在独立的挂载点独立数据盘上既能隔离容量风险也方便备份和迁移。如果条件允许日志目录和数据目录再分开比如 error log、binlog 都有自己的位置这样排查问题的时候路径一目了然。3.2 创建运行用户并准备目录权限MySQL 服务绝不能用 root 运行。原因是纵深防御的基础原则即使 MySQL 被攻击者拿到代码执行权限也不能直接获得 root shell。官方提供的二进制包里自带安装脚本思路也要求先创建 mysql 用户groupadd mysql useradd -r -g mysql -s /bin/false mysql-r表示创建系统用户-s /bin/false表示该用户不能登录 shell进一步降低风险。接着创建数据目录和日志目录并把属主改为 mysql 用户mkdir -p /data/mysql/logs chown -R mysql:mysql /data/mysql注意这里不要漏了 logs 目录否则后面配置慢查询日志、错误日志的时候MySQL 会因为目录不存在而拒绝创建日志文件进程直接异常退出。3.3 编写 my.cnf 配置文件MySQL 会依次读取多个位置的配置文件常见路径包括/etc/my.cnf、/etc/mysql/my.cnf、$basedir/my.cnf等。为了统一管理我通常把配置集中在/etc/my.cnf里边的基础内容如下[mysqld] basedir/usr/local/mysql datadir/data/mysql socket/tmp/mysql.sock pid-file/data/mysql/mysql.pid log-error/data/mysql/logs/error.log slow_query_log1 slow_query_log_file/data/mysql/logs/slow.log long_query_time2 port3306 server-id1 character-set-serverutf8mb4 collation-serverutf8mb4_general_ci default-storage-engineInnoDB max_connections500 innodb_buffer_pool_size2G几个参数逐个解释一下。basedir和datadir指定了二进制目录和数据目录这是所有路径配置的核心。socket/tmp/mysql.sock是本地客户端通过 Unix socket 连接的路径很多报错都是因为客户端和服务端的 socket 路径不一致导致的。character-set-serverutf8mb4已经是现代应用的标配utf8mb4 完整支持所有 Unicode 字符包括 emoji 和生僻汉字老的 utf8 字符集实际只能存 3 字节的编码会丢字符。innodb_buffer_pool_size是 InnoDB 最重要的内存参数建议设置为物理内存的 50% 到 70%但如果是多实例部署需要按实例均分。自检技巧写完配置后可以先用mysqld --defaults-file/etc/my.cnf --verbose --help | grep -E ^datadir|^basedir检查配置是否被正确读取避免因为配置路径写错导致服务起不来。3.4 初始化数据目录MySQL 5.7 开始废弃了老的mysql_install_db工具改用mysqld --initialize直接初始化数据目录。这一步会在 datadir 中创建 mysql 系统库、InnoDB 系统表空间、redo log 等基础文件。注意两条命令的区别# 方式一生成随机 root 临时密码输出到错误日志 /usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf --initialize --usermysql # 方式二生成空 root 密码适合测试环境初始化后立即设置密码 /usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf --initialize-insecure --usermysql生产环境推荐用方式一。初始化完成后临时密码在 error log 里直接搜索即可grep temporary password /data/mysql/logs/error.log如果采用空密码的方式初始化后要做的第一件事就是登录并修改密码这就引出了后面 3.6 的内容。3.5 启动服务与设置开机自启启动 MySQL 的方式有三种mysqld_safe、mysql.server、systemd。MySQL 官方二进制包自带的support-files/mysql.server脚本本质上是调用了mysqld_safe守护进程它会监控 mysqld 的运行状态并在崩溃时尝试自动拉起。这种方式在 SysVinit 的系统上很好用但在现代 systemd 系统上我更推荐自己写一个 systemd unit 文件这样开机自启、失败重启、日志管理都交给 systemd 统一处理。在/etc/systemd/system/mysqld.service中写入[Unit] DescriptionMySQL Server Afternetwork.target [Service] Usermysql Groupmysql ExecStart/usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf LimitNOFILE65535 Restarton-failure [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl start mysqld systemctl enable mysqldLimitNOFILE必须设置MySQL 高并发状态下会打开大量文件句柄系统默认的 1024 很快就会被耗尽表现为连接报错Too many open files。Restarton-failure让 mysqld 意外退出时自动重启减少单点故障对业务的影响。3.6 首次登录、修改密码与安全加固服务启动后用临时密码登录如果初始化时用的--initialize方式/usr/local/mysql/bin/mysql -uroot -p登录后不要急着配置业务先做三件安全基础工作。第一修改 root 密码。5.7 版本的密码字段和旧版本不同直接执行ALTER USER即可语法如下ALTER USER rootlocalhost IDENTIFIED BY NewStrongPassword;第二删除默认的匿名用户。MySQL 初始化时默认可能有空用户名的匿名账号这些账号虽然没有密码却能在本机以任意用户名登录必须清掉DELETE FROM mysql.user WHERE user; FLUSH PRIVILEGES;第三创建独立的业务账号而不是让业务系统直连 root。业务账号尽量限定主机和库表范围CREATE USER app192.168.%.% IDENTIFIED BY AppPassword123; GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO app192.168.%.%; FLUSH PRIVILEGES;这个做法的好处是即使业务账号被破解攻击者也无法访问其他库更不能执行 DDL 操作。root 账号只保留在本地使用禁止远程连接这是最基本的数据库安全底线。4. 安装过程中常见的坑与排查实录这一节记录的是我在 aarch64 平台安装 MySQL 时实际遇到过的几个典型问题每一个都曾经卡住过我不少时间。整理成速查表如下方便直接对照检查故障现象根本原因解决方案libaio.so.1: cannot open shared object file缺少 libaio 动态库yum install -y libaio或apt install -y libaio1libc.so.6: version GLIBC_2.28 not found系统 glibc 版本低于编译要求升级系统非手动升级 glibc或换用低 glibc 版本的 MySQL 包Cant connect to local MySQL server through socket /tmp/mysql.sockMySQL 未启动或 socket 路径不一致检查进程是否存活systemctl status mysqld核对 my.cnf 中的 socket 路径[ERROR] InnoDB: Operating system error number 13 in a file operation数据目录权限不足或 SELinux 拦截检查 datadir 属主确认 SELinux 对数据目录的上下文配置[ERROR] Could not open /data/mysql/logs/error.log日志目录不存在或没有写权限提前创建目录并chown mysql:mysql4.1 libaio 缺失这个错误我几乎每次在新环境安装都会遇到。症状是 mysqld 一启动就报错退出看错误日志才能发现动态库缺失。解决办法很简单根据系统发行版安装对应的包即可。这里有个容易踩的小坑有些精简版的系统镜像连yum/apt的缓存源都没有更新安装前先yum makecache或apt-get update否则会报“找不到软件包”。4.2 GLIBC_2.28 not found不要手动升级 glibc这是很多拿到新版本 MySQL 包的朋友最容易崩溃的错误。报错的意思是二进制包运行时依赖的 glibc 符号版本在系统当前 glibc 中不存在。遇到这个问题的第一反应千万不要是手动下载 glibc 源码去编译升级这个操作一旦出错系统可能连/bin/ls都跑不起来。正确处理方式有两种。一是升级操作系统到内置 glibc 2.28 以上版本的系统——注意是升级操作系统不是单独升 glibc。比如已有的 CentOS 7glibc 2.17可以迁移到较新的系统版本如 CentOS 时代的较新版本或改用基于更高 glibc 的现代发行版。二是找一个基于更低 glibc 编译的 MySQL 包比如官方历史上为 CentOS 7 提供的通用 Linux x86_64 包或者基于 aarch64 的适配包。第三条路是干脆用 Docker 镜像镜像内自带了合适的运行库绕开宿主机 glibc 版本限制。总之手动升级 glibc 是我个人强烈不建议的路径风险远大于收益。4.3 socket 连接失败的定位思路本地客户端连 MySQL 时报Cant connect to local MySQL server through socket /tmp/mysql.sock第一反应应该是确认服务到底有没有在跑。ps aux | grep mysqld看一下进程ss -lntp | grep 3306看一下端口监听状态。如果进程没跑去看 error log 找退出的真正原因。如果进程在跑但 socket 路径不对多半是客户端和服务端读取的 my.cnf 不一致在 mysql 客户端连接时显式指定 socket 路径可以快速验证mysql -S /tmp/mysql.sock -uroot -p。4.4 AppArmor / SELinux 导致的权限问题这个问题比较隐蔽。Ubuntu 上 AppArmor 默认对 MySQL 的数据目录有约束策略如果你把 datadir 自定义到了/data/mysqlAppArmor 的配置文件中没有这个路径就会拒绝访问。CentOS/RHEL 系列的 SELinux 同理。排查手段是看 audit 日志比如grep -i denied /var/log/audit/audit.log如果确认是安全模块拦截测试环境可以临时放行生产环境还是建议把数据目录加进白名单或调整上下文。4.5 初始化之后 mysql 命令键反了 / 登录报错实际操作中还有一个容易忽略的问题顺手把/usr/local/mysql/bin加入 PATH 的时候容易覆盖系统自带的 mysql 客户端版本。比如系统自带的是 MariaDB 客户端或者另一个版本的 MySQL 客户端登录时可能因为协议不兼容导致报错。建议在/etc/profile.d/mysql.sh中单独写一行export PATH/usr/local/mysql/bin:$PATH然后重新登录 shell 或者source一下。这样在终端里直接输入mysql就是新安装的客户端避免版本错乱。5. 安装完之后的日常运维小提醒服务能跑起来只是第一步几个细节值得在安装完成之后顺手做好。比如把/usr/local/mysql/bin加进 PATH这样日常执行mysql、mysqldump不用写全路径。再比如定期检查 error log 的大小MySQL 运行时间长了error log 里会积累大量访问日志和告警信息建议配置日志轮转。另外如果业务量还在增长后续要关注innodb_buffer_pool_size和max_connections是否贴近瓶颈aarch64 平台上的 MySQL 调优思路和 x86_64 基本一致核心还是先看内存、磁盘 I/O 和慢查询日志。根据我个人在 aarch64 服务器上的实操体会这个包只要提前确认好 glibc 版本和数据目录权限安装过程其实非常顺利。最后再分享一个小技巧安装过程中每执行完一个关键步骤都顺手用echo $?确认返回码为 0尤其是在初始化数据目录和启动服务这两个节点。这个习惯让我避免过不少“假装成功、后面连环报错”的局面——比如初始化因为目录权限失败但提示不明显后面启动服务时错误日志才暴露真正原因。写脚本自动化安装的话这个习惯尤其重要。本文还有配套的精品资源点击获取