MySQL 5.7.32 ARM二进制包部署：aarch64环境初始化与避坑指南

简介mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz 是为 ARM64AArch64Linux 环境预编译的 MySQL 5.7.32 官方二进制发行包面向树莓派 4、ARM 云服务器等设备的使用者可直接部署数据库而无需手动编译。压缩包约 510.16MB共 14882 个文件其中 result、inc、cnf、so、pem 等类型分别对应测试用例、头文件、配置模板、动态库与安全证书附带数据目录、日志及 binlog 样例结构完整便于排查维护。已有 1418 人学习下载。该包的价值不只是免编译安装更在于通过内置的 mysqld、mysql_secure_installation、mysql_upgrade 等工具以及清晰的目录组织帮助 ARM 用户快速完成初始化、安全加固和日常运维对希望掌握 MySQL 在非 x86 平台运行机制的开发者同样有参考意义。1. 一份 MySQL 5.7.32 ARM 二进制包值不值得自己折腾编译先给结论如果你手头是一台 arm aarch64 的 Linux 服务器某云的鲲鹏机型、飞腾机器或者自建的树莓派、RK3588 开发板装 MySQL 第一反应别去源码编译风险太大直接找官方编译好的 ARM 版 glibc tar.gz 是效率最高的路线。这个包的后缀linux-glibc-2.28-aarch64看着长其实信息量很密——aarch64 指 CPU 架构glibc-2.28 指动态链接器的最低版本要求它对应的是 MySQL 官方对 ARM 平台的通用二进制分发而不是某发行版带过的定制版。这篇笔记会把「这个包能用在哪、怎么装上、装完哪些参数必须动、哪些坑我踩过」一次说透。适合正在 ARM 服务器上部署生产或测试库的从业者也适合想绕过编译流程尽快起一个可用环境的新手。2. 拿到 tar.gz 先看懂三件事架构、glibc 兼容性、启动方式2.1 为什么是 aarch64 而不是 armv7 / x86_64先拉齐一个概念。aarch64是 ARM 的 64 位指令集平时说的 ARM64 就是它。常见的 ARM 服务器 CPU某云的鲲鹏 920、飞腾 FT-2000还有 Ampere Altra跑的全是 aarch64。而以前的树莓派 3B 那种 32 位 ARMv7 核跑不了这个包装了会报Exec format error这个和 go 编译出的二进制架构不匹配一个道理。判断你的机器是不是 aarch64最快的方式uname -m # 输出 aarch64 说明没问题 # 输出 armv7l 或 armhf这块包就装不了 ldd --version | head -n1第一句是看 CPU 架构第二句是看 glibc 版本。linux-glibc-2.28要求系统 glibc 版本不低于 2.28比如某发行版 22.04 的 glibc 是 2.35能装某发行版 18.04 的 glibc 是 2.27装完启动会报version GLIBC_2.28 not found。这是最经典的一个兼容性坑后面避坑章具体展开。2.2 tar.gz 解压后的目录结构和官方 rpm 系的差异这份资源解压后是一个mysql-5.7.32-linux-glibc-2.28-aarch64目录里面带有bin/、lib/、share/、support-files/等目录。它和用apt install mysql-server装出来的最大区别是没有/etc/mysql/my.cnf预设配置没有systemd服务文件没有自动创建的mysql系统用户。一切初始化都得自己动手好处是路径完全可控坏处是缺一步就起不来。我习惯把解压后的目录软链成/usr/local/mysql这样后续升级版本只需替换软链指向不用改一堆脚本里的硬编码路径mkdir -p /data/mysql tar -xzf mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz -C /usr/local ln -s /usr/local/mysql-5.7.32-linux-glibc-2.28-aarch64 /usr/local/mysql # 创建专用用户不让他登录 shell最小权限原则 groupadd mysql useradd -r -g mysql -s /bin/false mysql chown -R mysql:mysql /usr/local/mysql /data/mysql注意几个点解压路径放/usr/local下是 Linux 惯例放/opt也可以但/usr/local/mysql这个路径在大量 MySQL 文档和工具里是默认值别标新立异。useradd -r建的是系统账号-s /bin/false防止有人用这个账号登进 shell这些都是生产环境基线操作。/data/mysql是数据目录不要放在解压目录里后面初始化时单独指定理由后面讲。2.3 启动方式mysqld_safe 与 mysqld 直接跑的区别官方 tar 包不带 systemd 脚本启动方式有两个常规选择mysqld_safe和直接mysqld --daemonize。# 方式一mysqld_safe自带日志重定向、崩溃重启逻辑 /usr/local/mysql/bin/mysqld_safe --usermysql --datadir/data/mysql # 方式二daemonize 后台运行 /usr/local/mysql/bin/mysqld --usermysql --datadir/data/mysql --daemonize我一般用mysqld_safe。它的优势是 mysqld 进程意外退出后会自动拉起来而且默认把错误日志写到--datadir目录的*.err文件里排查问题直接tail -f那个文件。--daemonize更干净但进程挂了没人管。测试环境随意生产环境我建议要么mysqld_safe要么自己写 systemd unit 文件不要裸奔。3. 从零初始化到能连上库完整手工部署流程3.1 第一步初始化数据目录MySQL 5.7 把原来的mysql_install_db废弃了初始化入口统一成了mysqld --initialize。初始化会往数据目录写入系统库mysql、performance_schema、sys并生成一个临时 root 密码打印到错误日志里。/usr/local/mysql/bin/mysqld --initialize \ --usermysql \ --basedir/usr/local/mysql \ --datadir/data/mysql \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_general_ci # 初始化完成后从错误日志里找临时密码 grep temporary password /data/mysql/*.err几个关键参数说明--basedir指向解压目录--datadir指向数据目录这两个参数必须显式给否则 mysqld 会尝试用编译时默认路径/usr/local/mysql/data你会莫名其妙发现数据写到了别处。--character-set-serverutf8mb4是 5.7 里的一个最佳实践——如果不显式声明默认的是latin1存不了中文表情包和小语种字符业务上线后再改字符集特别疼表结构和索引都得重建。如果grep不到临时密码先确认初始化是否真的执行成功常见失败是--datadir目录非空后面避坑章细说。3.2 第二步启动实例并修改 root 密码初始化完成后就能启动了。注意一个容易被忽略的细节MySQL 5.7.32 初始化后root 账号默认只能在本地localhost登录并且初始状态是 locked 的需要通过临时密码登录后立刻改密码# 启动 /usr/local/mysql/bin/mysqld_safe --usermysql --datadir/data/mysql sleep 5 tail -n 20 /data/mysql/*.err # 用临时密码登录改密码 /usr/local/mysql/bin/mysql -uroot -p # 输入错误日志里的临时密码然后执行: # ALTER USER rootlocalhost IDENTIFIED BY YourNewPassword; # FLUSH PRIVILEGES;这个包的默认密码校验插件是validate_password_policy初始是MEDIUM意味着新密码必须包含数字、字母、大小写和特殊字符且长度不低于 8 位。如果不想在生产环境留这种复杂度约束可以在my.cnf里显式关闭但说实话我建议保留——ARM 服务器上跑的库经常是对外提供 API 的密码强度太低等于给扫描器送菜。3.3 第三步远端连接授权与最小配置落盘MySQL 装好后如果你只打算本机连这步可以跳过。但绝大多数场景是让应用服务器通过内网连过来所以需要授权一个非 root 账号并确认远端访问权限CREATE USER appuser10.0.0.% IDENTIFIED BY AppUser2024; GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO appuser10.0.0.%; FLUSH PRIVILEGES;注意appuser10.0.0.%里的 IP 段要换成你应用服务器的真实网段不要一上来就appuser%那是给自己留后门。MySQL 的授权是「用户 来源主机」双因子匹配appuserlocalhost和appuser192.168.1.7是两个不同的账号这点很多新手会犯迷糊。完成了这些一份最简可用的my.cnf也要同时落盘[mysqld] user mysql basedir /usr/local/mysql datadir /data/mysql port 3306 socket /tmp/mysql.sock character-set-server utf8mb4 collation-server utf8mb4_general_ci max_connections 200 innodb_buffer_pool_size 1G log_error /data/mysql/mysql-error.log这份配置的价值在于把关键路径和资源参数显式固定下来。max_connections 200是保守值先跑起来看监控再调innodb_buffer_pool_size 1G对应 4G 内存的 ARM 机器一个通用起步值后面单独讲怎么调。log_error单独指向文件别让它混在--datadir里的.err里排查问题更快。4. 配置落盘后的性能底子ARM 机器上必须动手的四个参数4.1 innodb_buffer_pool_size给头号内存消费者定额度InnoDB 的 buffer pool 是 MySQL 占内存的大头它缓存数据页和索引页直接决定热数据查询走内存还是走磁盘扫描。5.7 默认值是 128M对一个要跑真实业务的 ARM 服务器来说太小了。给多大合适一个经验主机物理内存的 50%~70%在 8G 内存的某云 ARM 机器上我一般给 4G~5G。# 查看当前值和 InnoDB 缓冲池命中率 SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads;第一个变量是总读请求次数第二个是从磁盘读的次数后者除以前者的比值越小命中率越高。如果命中率长期低于 97%buffer pool 大概率给小了。调大这个参数不需要重启可以动态改但生产环境我一般配合低峰期做 rolling restart避免运行中调整造成的性能抖动。4.2 innodb_flush_log_at_trx_commit性能与安全之间的取舍这个参数有三个值0、1、2。默认是 1意思是每次事务提交都要把 redo log 刷到磁盘保证数据库崩溃后用 redo 恢复时不丢已提交事务——这是最安全点同时也最费磁盘 IO。ARM 服务器的磁盘 IO 能力普遍弱于 x86 服务器很多同事上来就改成 2每秒刷一次 redo快是真快但宕机可能丢 1 秒的事务。我的折中做法是核心业务库保持 1统计分析库、日志类库改成 2。这个参数在my.cnf里改重启生效innodb_flush_log_at_trx_commit 1 sync_binlog 1sync_binlog 1是另一个和 redo 配合的安全参数控制 binlog 每次提交刷盘。两者都关了性能绝不是功能翻倍的提升但你可能赢得了一个「数据库莫名其妙的慢」的玄学问题。对 ARM 单机部署来说两台参数全开时的写入性能通常是最先触发瓶颈的先用大页缓存和 SSD 顶一阵然后再考虑主从分流。4.3 performance_schema低配机器上的资源消耗大户performance_schema 是 MySQL 5.7 默认开启的监控项它收集进程内部的等待、锁、IO 等细粒度数据运维排查时非常好用但代价是额外的内存和 CPU 消耗。在某云 2C4G 的 ARM 测试机上实测这个模块能占到 300M~500M 内存对配置有限的机器来说是不小的负担。performance_schema ON performance_schema_max_table_instances 300如果你的 ARM 机器内存不宽裕且有 zabbix 或 Prometheus 这类外部监控可以考虑关掉它换回几百 M 内存。但注意一旦关掉SHOW ENGINE INNODB STATUS里一些诊断信息就没了排查死锁只能靠日志和innodb_print_all_deadlocks参数来补。我通常的方案是 8G 内存以上就开着4G 内存就关掉外部监控兜底。4.4 lower_case_table_names初始化前想清楚初始化后不改这个参数决定表名和库名是否区分大小写。Linux 上 MySQL 默认值是 0区分大小写Windows 上默认是 1。如果你从 Windows 那边把一个库迁到 ARM Linux 上原来用大小写混合表名的建表语句到 Linux 上会报Table doesnt exist慌得很。设置方法是在初始化之前就写进my.cnflower_case_table_names 1为什么强调「之前」5.7 里lower_case_table_names在初始化之后改动会导致启动失败因为数据目录里的表名已经被记录成原样再改成 1 后对不上mysqld直接拒绝启动。这是个「后悔药吃不了」的参数上线前纠结清楚比上线后补救成本低得多。5. 避坑aarch64 机器上装 MySQL 的六条血泪记录5.1 解压后启动报mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file现象直接运行bin/mysqld或者bin/mysqld_safe终端直接报libaio.so.1找不到进程起不来。原因MySQL 官方二进制包依赖libaio异步 IO 库但 Debian/Ubuntu 系服务器默认不装这个包。x86 机器上很多发行版可能碰巧预装了ARM 机器的精简镜像几乎是裸系统缺这个库的概率极高。解决装依赖包不用动 MySQLapt-get update apt-get install -y libaio1 libnuma1如果机器不能连外网 apt可以从某发行版镜像站把libaio1的 deb 包拉下来装。别去自己编译 libaio没那个必要MySQL 官方文档里也是直接让你装依赖库。5.2 启动报GLIBC_2.28 not found现象mysqld启动报错用ldd bin/mysqld检查若干.so标记not found然后定位到GLIBC_2.28 not found。原因当前系统的 glibc 版本低于 2.28。linux-glibc-2.28-aarch64表示二进制要求的 glibc 最低版本是 2.28比如 CentOS 7 ARM、Debian 9 这类老系统的 glibc 停在 2.27直接跑不了。解决最干净的方案是升系统而不是去升级 glibc——手工替换系统 glibc 是 Linux 运维界公认的翻车操作一不小心整个系统所有命令全部崩掉。如果业务必须保留老系统唯一可行的尝试是找linux-glibc-2.17-aarch64之类的低版本包它在老系统上兼容性更好。5.3 初始化报[ERROR] --initialize specified but the data directory has files in it现象执行mysqld --initialize时终端直接给这个错误初始化失败。原因--datadir指向的目录已经非空通常是之前初始化失败残留了日志文件、系统库文件或者你把数据目录指到了解压目录里那里本就有一堆模板文件。解决把目录清空再初始化注意别误删已有数据rm -rf /data/mysql/* /usr/local/mysql/bin/mysqld --initialize \ --usermysql --basedir/usr/local/mysql --datadir/data/mysql如果你是在准备迁移数据这个目录里有旧库文件那就不是清空的问题而是路径配错了回头检查my.cnf里的datadir是否和旧库一致。5.4 初始化时报[ERROR] Could not create directory或Permission denied现象初始化命令执行到一半报无法创建目录或没有权限数据目录一直是空的。原因数据库--usermysql指向的账号没有--datadir路径的写权限。这个在 ARM 机上特别常见因为数据盘通常单独挂载在/data挂载点的父目录属主是 rootmysql 用户没权限写。解决mkdir -p /data/mysql chown -R mysql:mysql /data chmod 750 /data/mysql注意如果/data是自己挂载的独立盘确保挂载参数里没有noexec或nosuid会限制后续运行以及/data本身的属组也要让 mysql 可写。5.5 启动正常但本地mysql -uroot -p连不上报Access denied现象客户端连接报错Access denied for user rootlocalhost即使输入的密码是对的。原因这个包初始化时启用了 skip-name-resolve 或者 root 账号的 plugin 是auth_socket而不是mysql_native_password或者caching_sha2_password。解决先用 sudo 或直接以 mysql 用户身份进入sudo /usr/local/mysql/bin/mysql -uroot进去后执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY YourPassword; FLUSH PRIVILEGES;如果 sudo 也进不去停库后用--skip-grant-tables绕过认证表进去先把 root 密码重置再把权限表恢复锁定状态/usr/local/mysql/bin/mysqld_safe --skip-grant-tables --skip-networking 5.6 报错Table ./xxx/yyy is marked as crashed and should be repaired现象业务查询时报表损坏应用侧错误日志疯狂刷这个提示。原因ARM 服务器上最常见的原因是意外断电或异常重启数据文件没刷完。次因是磁盘 IO 故障数据页写了一半。解决对 MyISAM 表执行REPAIR TABLE对 InnoDB 表只能靠备份恢复或者用innodb_force_recovery把实例拉起来导出数据innodb_force_recovery 1这个参数从 1 到 6 逐级递增6 级时只读不再对数据文件做任何写操作。设成 1 启动成功后立刻用mysqldump导表导出后把参数注释掉再重启从备份或导出文件恢复数据。记住innodb_force_recovery是诊断工具不是长期运行参数。6. 加压验证装完到上线前至少完整走一遍这五步到这一步说明数据库已经能稳定跑起来了别急着交付。我每次在 ARM 机器上装完这个包都会强制把下面这五步走完缺一步都心里没底。这套流程是从一个生产事故后总结出来的——当时某个库上线第二天凌晨挂了恢复后发现是安装时漏了权限加固和备份演练。第一步重启验证。kill掉 mysqld 再起来一次确认mysqld_safe能自愈拉起 process并且数据目录没有产生新的错误日志kill $(pgrep -f mysqld_safe) sleep 3 pgrep -f mysqld_safe || /usr/local/mysql/bin/mysqld_safe --usermysql --datadir/data/mysql 如果这步失败大概率是上节第 5.5 条的认证问题没真正解决或者my.cnf里写坏了路径。第二步冷备验证。用 5.7 自带的mysqldump把核心库完整导一遍再导入一个临时库比对行数/usr/local/mysql/bin/mysqldump \ --single-transaction --quick \ -uroot -pYourPassword \ appdb /backup/appdb.sql /usr/local/mysql/bin/mysql -uroot -pYourPassword -e CREATE DATABASE appdb_bak DEFAULT CHARSET utf8mb4; /usr/local/mysql/bin/mysql -uroot -pYourPassword appdb_bak /backup/appdb.sql--single-transaction对 InnoDB 表做一致性快照不加锁不加负担线上备份必须带这个参数。--quick防止大表把内存撑爆。如果导入后行数和线上对得上说明备份链路可用这比什么书面承诺都靠谱。第三步连接池测试。模拟应用端的真实并发连接用系统自带的mysqlslap加压不需要额外装工具/usr/local/mysql/bin/mysqlslap \ --host127.0.0.1 --port3306 \ --userappuser --passwordAppUser2024 \ --concurrency50 --iterations10 \ --querySELECT COUNT(*) FROM appdb.orders \ --create-schemaappdb--concurrency50是同时起的线程数--iterations10是每个并发连执行次数这两个值决定测试时长和压力级别。观察输出里的平均耗时如果单次查询平均耗时超过 200ms就要回头看 buffer pool 设置和磁盘 IO 了。第四步慢查询确认。打开慢查询日志再跑一轮上面的mysqlslap然后看日志里有没有漏网的大查询slow_query_log ON long_query_time 1 slow_query_log_file /data/mysql/mysql-slow.loglong_query_time 1是秒数阈值超过 1 秒的语句都记。ARM 机器上最常见的两类慢查询一是没走索引的全表扫描二是跨网段访问数据库时的网络延迟被记成了慢查询。慢查询日志的价值在于区分「数据库慢」还是「网络慢」前者EXPLAIN查索引后者查应用服务器到数据库服务器的链路延迟。第五步磁盘可用空间确认。MySQL 5.7 的 binlog 如果不定期清理会一直膨胀下去ARM 服务器数据盘通常不大binlog 撑爆磁盘是我见过最高频的生产事故之一。上线前我必做的操作-- 查看 binlog 占用 SHOW MASTER STATUS; SHOW BINARY LOGS; -- 设置自动清理时长保留 3 天 SET GLOBAL expire_logs_days 3; FLUSH BINARY LOGS;expire_logs_days 3不是删一个 binlog是让 MySQL 自动删除超过 3 天的二进制日志。如果你做主从同步清理前确认从节点已经拉取完对应日志否则从节点断档后要重新做全量同步那才是大工程。从那以后我每次在 ARM 机器上装 MySQL都会强制自己把这五步完整走一遍再交付。第一次做很费时间后面熟练了半小时就能搞定但它保证了你拿到的不是一个「能 ping 通就交付」的黑匣子而是一个知道底层怎么跑、坏了怎么恢复的数据库实例。希望帮到你。本文还有配套的精品资源点击获取