简介面向ARM64架构Linux系统的MySQL 5.7.44二进制包适配国产麒麟v10等环境解决非x86平台编译安装难、依赖多的问题适合运维与开发人员在服务器、嵌入式或物联网网关等场景快速部署数据库。压缩包内含2000个文件其中test用例有876个便于安装后验证功能inc/h头文件与so动态库支撑二次开发opt/cnf/ini配置模板辅助参数调优sql与sh脚本覆盖初始化和自动部署流程整包约519MB。目前已有1893人学习。借助包内程序、库文件、配置样例和测试用例使用者可快速完成MySQL安装、调优与验证同时获得5.7.44版本的安全修复省去源码编译环节提升国产平台上线效率。 这个包我盯了很久。mysql-5.7.44-linux-aarch64.tar.gz看起来就是一个再普通不过的 MySQL 二进制包但真正要动手装的时候你会发现网上能找到的教程基本都是 x86_64 的照搬过来在 ARM 机器上跑轻则报错重则直接把数据目录搞残。“arm架构”这四个字才是这个包真正的门槛。我最近在一台 ARM Linux 服务器上完整走了一遍安装、初始化、配置、启动、优化的流程踩了不少坑也整理出了一套可以直接照做的路径。这篇东西就是给那些准备在 ARM 环境下部署 MySQL 5.7.44 的同行看的尤其是手里有旧业务、只能继续用 5.7 的老项目。1. 为什么 ARM 服务器非要单独的 MySQL 包MySQL 官方提供的 Linux 二进制包是按 CPU 架构分别编译的常见的有 x86_64 和 aarch64 两套。aarch64 就是 ARM 的 64 位指令集标题里的linux-aarch64指的就是这一套。ARM 架构的服务器这几年在机房里的占比越来越高功耗低、核心数多很多云厂商也开始提供 ARM 实例但软件生态的迁移速度明显跟不上硬件普及的速度MySQL 就是其中一类容易踩坑的基础软件。很多第一次接触 ARM 服务器的同学会想都是 Linuxx86 的包拷过来加个--force是不是也能跑答案是跑不了。MySQL 的二进制里包含大量针对特定处理器指令集编译的机器码ARM 和 x86 的指令集完全不通强行执行只会出现Exec format error。所以第一步必须确认你的机器是 ARM 的那你只能选aarch64或者armv7l对应的包而 64 位环境就用aarch64这个。另外一个容易被忽略的点是5.7.44 是 MySQL 5.7 系列的后期版本很多人还在用 5.7 的原因不是不想升级而是业务代码里大量使用了 5.7 的行为特性比如ORDER BY隐式排序、分区表限制、JSON 函数支持度等迁到 8.0 需要回归测试周期太长。所以 5.7.44 目前依然是许多生产环境的稳妥选择ARM 架构下继续用这个版本完全合理。2. 下载前先确认环境省得白折腾2.1 机器架构和系统版本要摸清楚不要以为写的是 ARM 就万事大吉ARM 也有 32 位和 64 位之分。先执行下面三条命令确认你手里机器的真实情况uname -m cat /etc/os-release lscpu | grep Architectureuname -m输出aarch64说明是 64 位 ARM这个包能用。输出armv7l或者armv6l是 32 位 ARM标题里这个aarch64包用不了得另找 32 位版本。输出x86_64那直接去下载普通 x86 版本别在这浪费时间。系统发行版方面mysql-5.7.44-linux-aarch64.tar.gz这种官方二进制包对发行版不敏感CentOS、Ubuntu、Debian、openEuler 这类常见的发行版都能跑前提是 glibc 版本不要太老。官方编包一般使用 glibc 2.12 或 2.17 的兼容基线太老的系统建议先升级glibc否则动态链接库会对不上运行时会报version GLIBC_X not found。2.2 依赖库必须提前装齐MySQL 5.7 的二进制包有几个运行时依赖缺了任何一个mysqld启动时会直接崩溃或者报共享库加载错误。最常见的是这三个libaio.so.1 libnuma.so.1 libncurses.so.5在 Debian/Ubuntu 系上安装apt-get update apt-get install -y libaio1 libaio-dev libnuma-dev libncurses5在 CentOS/RHEL 系上安装yum install -y libaio libaio-devel numactl numactl-devel ncurses-libs这里有一个非常典型的坑libaio 这个库在最小化安装的 ARM 系统中经常没带上缺失时mysqld启动会直接失败而且日志里只写一句error while loading shared libraries: libaio.so.1。这个我在后面专门讲排错的时候会重点展开。2.3 下载链接与文件完整性校验mysql-5.7.44-linux-aarch64.tar.gz的包名在不同镜像站点可能有细微差异有的站点会写成mysql-5.7.44-linux-glibc2.12-aarch64.tar.gz多了一个glibc2.12的标识表示编译时用的 glibc 兼容级别实际安装流程完全一样。建议优先从 MySQL 官方下载页或者可信的镜像源获取下载完成后务必校验 MD5md5sum mysql-5.7.44-linux-aarch64.tar.gz官方文档里给出的 MD5 值要严格比对不对就千万别解压。ARM 环境下因为下载中断或者磁盘问题导致包损坏的概率其实不低我见过有人解压到一半发现文件缺失然后疯狂排查系统问题最后才意识到是包坏了。3. 从 tar.gz 到可用的 MySQL 服务完整操作实录3.1 用户、目录与解压的规范姿势MySQL 官方强烈建议用专用的系统用户运行不要用 root这是安全基线的一部分。先创建用户和用户组groupadd mysql useradd -r -g mysql -s /bin/false mysql-s /bin/false表示这个用户不能登录 shell只用来跑服务减少被攻击时的危害面。然后是解压路径。我习惯放在/usr/local下面解压后做一个软链好处是以后升级版本只需要替换软链指向不影响配置和启动脚本tar -xzvf mysql-5.7.44-linux-aarch64.tar.gz -C /usr/local cd /usr/local ln -s mysql-5.7.44-linux-aarch64 mysql数据目录单独规划。不要把数据放在解压目录里生产环境一定要单独建数据盘或者分区这样将来重装系统、升级版本数据可以完整保留mkdir -p /data/mysql chown -R mysql:mysql /data/mysql chmod 750 /data/mysql3.2 my.cnf 的核心配置思路5.7 对配置文件的位置有固定搜索顺序/etc/my.cnf是最常用的。下面给出一份适合大部分 ARM 服务器的入门配置重点是内存相关的参数不要按 x86 服务器的经验拍脑袋写。[mysqld] basedir/usr/local/mysql datadir/data/mysql socket/tmp/mysql.sock pid-file/data/mysql/mysqld.pid port3306 character-set-serverutf8mb4 lower_case_table_names1 max_connections500 innodb_buffer_pool_size1G innodb_log_file_size256M innodb_flush_log_at_trx_commit1 sync_binlog1 server-id1 log-bin/data/mysql/binlog几个参数需要解释一下innodb_buffer_pool_sizeInnoDB 的缓冲池一般设为物理内存的 50% 到 70%。但 ARM 服务器的内存往往比 x86 服务器小比如有些 ARM 开发板只有 4G 内存设 1G 是一个比较稳妥的起点。innodb_flush_log_at_trx_commit1和sync_binlog1是保证数据安全性的典型配置代价是写入性能下降如果只是内部测试环境可以改成0和2能明显提升写入速度。lower_case_table_names1表示表名不区分大小写MySQL 官方文档说 Linux 平台默认是 0但很多从 Windows 迁移过来的业务代码都习惯小写表名设成 1 可以减少迁移后的兼容性问题但需要注意改这个参数必须在初始化数据目录之前确定否则后续改会非常麻烦。3.3 初始化数据目录与初始密码确认目录权限没问题后执行初始化命令cd /usr/local/mysql bin/mysqld --defaults-file/etc/my.cnf --initialize --usermysql这一步的作用是创建 MySQL 系统表空间、数据字典和 root 初始密码。注意--initialize会生成一个临时随机密码打印到错误日志里如果希望初始密码为空方便首次登录可以使用--initialize-insecure但生产环境绝对不要用这个。初始化完成后错误日志默认在/data/mysql/*.errCentOS 上也有可能在/var/log/mysqld.log里会出现类似这一行[Note] A temporary password is generated for rootlocalhost: xxxxxxxx把这一串临时密码复制下来。初始化阶段如果遇到报错先别急着重试去看日志最后几行大部分原因都能在上面的[ERROR]级别日志里直接找到。磁盘满了、目录权限不对、内存不足都会在这个阶段暴露。3.4 首次启动、修改密码与创建业务账号初始化成功后启动服务/usr/local/mysql/bin/mysqld_safe --defaults-file/etc/my.cnf 等 3 到 5 秒后检查进程和端口ps -ef | grep mysqld ss -tlnp | grep 3306进程在、3306 端口在监听说明基本成了。然后用临时密码登录/usr/local/mysql/bin/mysql -uroot -p登录后 MySQL 会强制要求先改密码因为 5.7 默认安装了密码校验插件ALTER USER rootlocalhost IDENTIFIED BY YourNewStrongPassword;接下来创建一个业务专用账号避免所有应用都拿 root 去连库CREATE USER appuser% IDENTIFIED BY AppUserPass123; GRANT ALL PRIVILEGES ON appdb.* TO appuser%; FLUSH PRIVILEGES;到这里一个最小可用的 MySQL 5.7.44 服务就已经跑起来了。4. ARM 环境下最容易翻车的几个坑4.1 libaio 缺失启动即崩的元凶这个坑出现频率太高必须单独拿出来说。在干净安装的 ARM 系统上尤其是用 Docker 基础镜像或者云厂商最小化镜像初始化的环境经常会缺少libaio。启动mysqld的时候你会看到error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory很多人这时候开始怀疑是不是包有问题重下好几次但其实只是因为少装了一个系统库。安装完libaioUbuntu 用apt-get install libaio1CentOS 用yum install libaio之后问题立刻消失。这个报错在 x86 系统里同样会出现但在 ARM 最小化镜像里出现的概率尤其大因为镜像裁剪者通常不会考虑数据库依赖。4.2 初始化时报错 Could not allocate memoryARM 设备的内存偏小如果 my.cnf 里把innodb_buffer_pool_size调得过大初始化的时候可能会报[ERROR] InnoDB: Cannot allocate memory for the buffer pool原因很简单buffer pool不是一次性分配成功的而是在启动阶段连续分配大量内存物理内存不足时内核拒绝分配。对策有两个方向一是调低innodb_buffer_pool_size比如 1G 内存的机器就设成 256M二是确保没有其他大内存服务在跑。在 ARM 开发板上跑 MySQL 的人往往同时还在跑 Nginx、Java 应用、Redis这就更容易触发内存不足。4.3 systemd 服务和 init 脚本的差异mysql-5.7.44-linux-aarch64.tar.gz这个包自带的是support-files/mysql.server脚本这个脚本是 System V init 风格的在很多新版 Linux 系统上直接执行也能工作但无法开机自启。建议写一个 systemd 服务文件内容模板如下[Unit] DescriptionMySQL 5.7.44 Server Afternetwork.target [Service] Typeforking Usermysql Groupmysql PIDFile/data/mysql/mysqld.pid ExecStart/usr/local/mysql/support-files/mysql.server start ExecStop/usr/local/mysql/support-files/mysql.server stop ExecReload/usr/local/mysql/support-files/mysql.server restart PrivateTmptrue [Install] WantedBymulti-user.target保存为/etc/systemd/system/mysqld.service然后systemctl daemon-reload systemctl enable mysqld systemctl start mysqld要注意PIDFile路径必须和my.cnf里pid-file一致否则 systemd 会一直警告找不到 PID 文件甚至误判服务启动失败。4.4 数据目录初始化失败后的清理动作初始化失败后数据目录里很可能已经残留了部分系统表文件。如果直接重新执行--initialize会报[ERROR] --initialize specified but the data directory has files in it。正确的处理方法是把数据目录里的残留文件全部删掉再重试rm -rf /data/mysql/*但前提是你确认目录里没有重要的业务数据。如果是第一次初始化那没问题如果是从旧实例迁移过来的那绝对不能直接删除要先备份。很多人就是因为手快一条rm -rf把之前的数据全带走了。5. ARM 服务器上 MySQL 的调优与安全加固5.1 根据实际内存做一轮参数调整MySQL 跑起来能用了离“能用得好”还有距离。ARM 服务器的内存模型和 x86 有些差异最明显的一点是很多 ARM 服务器同时是低功耗设计内存频率和带宽没有 x86 服务器那么夸张所以 InnoDB 缓冲池大小和连接数要更加克制。你可以等业务稳定跑一段时间后用下面这句 SQL 看一下当前实际的缓冲池命中率SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_hit%;如果命中率在 99% 以下说明缓冲池偏小如果长期在 99.9% 以上并且内存还有富余可以适当调大innodb_buffer_pool_size。另外max_connections不要太贪ARM 服务器上每个连接都会消耗线程栈内存默认 500 连接在某些 4G 内存的机器上会直接把内存吃光可以先从 200 开始跑。连接缓存和线程池方面的参数5.7 默认的thread_cache_size只有 9可以调到 16 到 32。表缓存table_open_cache默认 2000对于大部分业务够用。这些参数都不用一次性追求最优跑起来之后观察SHOW GLOBAL STATUS里的Threads_connected、Open_tables、Threads_created三个指标逐步调整。5.2 安全基线远程访问、匿名用户和测试库安装完成后有几件安全事项必须立刻做删除匿名用户DELETE FROM mysql.user WHERE User; FLUSH PRIVILEGES;删除默认测试数据库DROP DATABASE IF EXISTS test;限制远程 root 登录SELECT user, host FROM mysql.user WHERE Userroot;生产环境下 root 一般只允许 localhost 登录。如果业务确实需要远程连接单独创建带最小权限的账号而不是直接允许 root 远程。开启防火墙规则只放行必要来源的 3306 端口。ARM 服务器很多跑的是边缘计算或内网业务端口暴露过宽是大忌。5.3 ARM 环境下备份和版本升级的额外建议ARM 架构下的 MySQL 数据文件和 x86 架构在逻辑层面是二进制兼容的但跨架构做物理备份恢复时最好先把数据用mysqldump导出成逻辑 SQL再在另一套架构上导入避免潜在的字节序差异和 InnoDB 兼容性问题。MySQL 官方的二进制包之间是通用的也就是说你把/data/mysql目录从 x86 迁移到 ARM 实例上直接用很多情况下确实能跑但这不是官方推荐的路径真出了问题没人替你兜底。定时写一个简单的逻辑备份脚本放到 cron 里比如每天凌晨 2 点执行/usr/local/mysql/bin/mysqldump -uroot -pYourPassword --single-transaction --all-databases | gzip /backup/mysql_$(date \%F).sql.gz--single-transaction参数在 InnoDB 引擎下可以做到不锁表备份是 5.7 时代最常用的备份方式。走完这一整套流程ARM 架构上的 MySQL 5.7.44 已经是一个可以稳定服务的状态了。我自己反复验证过多次最关键的一点就是把“ARM 架构”当成一个正经的部署场景来对待而不是默认它和 x86 完全一致。如果你也是第一次在 ARM 机器上装 MySQL按这个流程走一遍应该能少走不少弯路。最后再提一句所有配置改动后都要用mysqladmin -uroot -p ping确认连接正常再切流别改完配置直接杀进程那种操作方式最容易把小问题放大成大故障。本文还有配套的精品资源点击获取