MySQL 4.1.18 老32位tar包部署指南：从解压到迁移的避坑实践

简介这份资源是 MySQL 4.1.18 的 Linux 二进制安装包面向需要在 i686 架构、glibc23 环境下部署数据库的初学者与运维人员可用于搭建轻量级应用后台或学习关系型数据库的基础管理。压缩包共 1269 个文件约 24.48MB以 result、test、opt 等测试与配置类文件为主同时包含 h、inc 头文件、txt 说明文档、cfg 与 cnf 配置样例、sh 脚本以及 mysqld、mysqladmin、mysqldump 等核心可执行程序覆盖服务端、客户端与常用管理工具。目前已有 131 人学习下载。通过该包可完成解压、初始化与启动流程理解 mysql 与 test 两个内置库的用途掌握 root 空密码修改、GRANT/REVOKE 权限分配并借助 mysqldump、mysqlcheck、mysql_secure_installation 等工具练习备份、检查与安全加固为后续数据库运维打下基础。1. 老 32 位 tar 包还能不能用mysql-standard-4.1.18 的定位与适用边界手里拿到一个mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar第一反应往往是「这年头谁还用 4.1」。但真到某些封闭环境里比如老工控机、内网遗留业务、跑在 i686 架构上的采集程序能直接解压就跑的 MySQL 二进制包反而是最省事的方案。这个包是 MySQL 官方当年为 Linux x86i686编译的 standard 版依赖 glibc 2.3 系列解压即用不需要编译也不需要联网装依赖。它解决的核心问题就一个在没有包管理器、没有编译工具链、甚至没有 root 的环境里把一套能连能查的 MySQL 跑起来。适合谁维护老系统的运维、做离线部署的交付工程师、以及需要复现历史环境做数据迁移的人。不适合新项目也不适合对安全补丁有硬要求的场景。2. 解压与初始化从 tar 包到能启动的数据库目录2.1 先确认架构和 glibc 版本别急着 tar -zxvf很多人拿到 tar 包直接tar -zxvf结果解压完启动报FATAL: kernel too old或者GLIBC_2.3 not found。这个包是 i686 的跑在 x86_64 机器上虽然能解压但二进制本身是 32 位的需要系统装了 32 位兼容库。先做两件事确认 CPU 架构和 glibc 版本。uname -m # 输出 i686 或 i386 说明是 32 位系统可直接用 # 输出 x86_64 说明是 64 位系统需要确认是否装了 32 位运行库 ldd --version | head -1 # 看 glibc 版本2.3 以上基本兼容但 2.3 之前的系统跑不了如果uname -m是 x86_64检查/lib/ld-linux.so.2是否存在不存在就得先补 32 位兼容库。这一步不做后面全是白费。常见做法是先rpm -qa | grep glibc看装了哪些 glibc 包再决定要不要补 i686 版本。2.2 解压路径和目录规划别放在 /tmp 里tar 包解压出来是一个完整的 MySQL 目录树包含bin、libexec、share、support-files等。建议放到一个固定路径比如/opt/mysql或/usr/local/mysql不要放/tmp因为 MySQL 启动后会在数据目录里持续写文件/tmp被清理会导致数据库直接挂掉。mkdir -p /opt/mysql tar -zxvf mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar -C /opt/mysql # -C 指定解压目标目录解压后通常多一层同名目录 ls /opt/mysql # 确认解压结果进入实际目录解压后进入目录先看bin下有没有mysqld、mysql、mysqladmin这几个关键二进制。如果mysqld存在但执行报No such file or directory大概率是 32 位动态链接器缺失用file bin/mysqld确认架构再用ldd bin/mysqld看缺哪个库。2.3 初始化数据目录mysql_install_db 的正确用法4.1 版本还没有mysqld --initialize初始化靠scripts/mysql_install_db。这个脚本会创建mysql和test两个库并生成 root 用户。关键参数是--basedir和--datadir不指定的话它会按编译时的默认路径找大概率找不到。cd /opt/mysql/mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 ./scripts/mysql_install_db \ --basedir/opt/mysql/mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 \ --datadir/opt/mysql/data \ --usermysql # --basedir 指向解压后的 MySQL 根目录 # --datadir 是数据目录必须提前创建并授权给 mysql 用户 # --user 指定运行 mysqld 的系统用户不指定会用当前用户如果报FATAL ERROR: Could not find mysqld说明--basedir写错了脚本会在basedir/bin和basedir/libexec下找mysqld。如果报Cant create/write to file检查datadir权限chown -R mysql:mysql /opt/mysql/data再重试。初始化完成后datadir下会出现mysql目录和ibdata1等文件说明成功。2.4 配置文件 my.cnf 的最小集与启动验证4.1 的配置文件读取顺序是/etc/my.cnf、$basedir/my.cnf、~/.my.cnf。为了避免和系统里其他 MySQL 冲突建议在basedir下放一个独立的my.cnf启动时用--defaults-file显式指定。[mysqld] basedir/opt/mysql/mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 datadir/opt/mysql/data port3306 socket/tmp/mysql.sock usermysql old_passwords1old_passwords1是 4.1 的关键参数因为 4.1 引入了新的密码哈希算法但很多老客户端只支持旧算法不设这个后面连接会报Client does not support authentication protocol。启动命令bin/mysqld_safe --defaults-file/opt/mysql/my.cnf # mysqld_safe 是守护脚本挂了会自动拉起 # 启动后看 datadir 下的 .err 文件确认是否正常 tail -20 /opt/mysql/data/*.err看到mysqld started和ready for connections就算起来了。然后用bin/mysql -uroot -S /tmp/mysql.sock连接能进mysql提示符就说明整条链路通了。3. 连接与权限老版本认证协议和 socket 路径的坑3.1 密码哈希算法old_passwords 与 4.1 认证协议4.1 的默认密码哈希是 41 位十六进制而 4.0 及更早客户端只认 16 位。如果你用老版本的 PHP mysql 扩展或老版 Navicat 连接会直接报认证失败。解决办法有两个一是服务端设old_passwords1二是建用户时用OLD_PASSWORD()函数。SET PASSWORD FOR appuser% OLD_PASSWORD(yourpass); -- OLD_PASSWORD 生成 16 位哈希兼容老客户端 -- 不写 OLD_PASSWORD 则用新算法新客户端才能连注意old_passwords1只影响新建用户和改密码时的默认行为已经用新算法存好的密码不会自动变。如果已经建了新算法的用户要么改密码要么升级客户端。常见做法是内网统一用旧算法外网或新客户端用新算法但 4.1 不支持同一用户双算法只能二选一。3.2 socket 连接失败error 2002 的排查顺序ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock是 4.1 时代最高频的报错。原因通常有三个mysqld 没起来、socket 路径不一致、socket 文件权限不对。排查顺序ps aux | grep mysqld # 先确认进程在不在不在就看 .err 日志 grep socket /opt/mysql/my.cnf # 确认配置里的 socket 路径 ls -l /tmp/mysql.sock # 确认文件存在且 mysql 用户可读写如果客户端不指定-S它会按编译默认路径找 socket而你的 socket 在/tmp/mysql.sock路径对不上就报 2002。连接时显式加-S /tmp/mysql.sock或者在my.cnf的[client]段也写上socket/tmp/mysql.sock让客户端自动读取。3.3 远程连接与 bind-address4.1 没有 skip-networking 的默认值4.1 默认监听所有网卡但如果你在my.cnf里写了skip-networking就只能走 socket远程连不上。另外 4.1 没有bind-address参数控制监听地址靠skip-networking和防火墙。远程连接报Host x.x.x.x is not allowed to connect时先确认用户表里的 host 字段。USE mysql; SELECT host, user FROM user; -- 看是否有 % 或具体 IP 的记录 GRANT ALL ON *.* TO appuser% IDENTIFIED BY yourpass; FLUSH PRIVILEGES; -- 4.1 的 GRANT 语法和 5.x 基本一致但不支持 CREATE USER改完权限表必须FLUSH PRIVILEGES否则不生效。如果还是连不上用telnet 目标IP 3306确认端口通不通不通就是防火墙或skip-networking的问题。4. 避坑与排查4.1 tar 包部署的五个血泪经验4.1 现象启动报 FATAL: kernel too old原因内核版本低于编译目标解决换包或升内核这个报错说明二进制编译时用的内核头文件比当前系统新。4.1.18 官方包编译目标比较老一般不会遇到但如果你在很老的发行版上跑或者包被重新编译过就可能出现。先uname -r看内核版本如果低于 2.4基本没救只能找更老的包或升级系统。如果内核不低但还报检查是不是拿了 x86_64 的包在 i686 上跑架构不匹配也会报类似错误。4.2 现象mysql_install_db 报 Could not find ./bin/my_print_defaults原因basedir 路径不对解决用绝对路径重跑mysql_install_db内部会调用bin/my_print_defaults读配置如果--basedir写的是相对路径脚本切换目录后就找不到了。血泪经验是永远用绝对路径而且不要在有软链接的路径上跑软链接解析后可能和预期不一致。重跑前先删掉datadir下的残留文件否则会报data directory already exists。4.3 现象连接报 Client does not support authentication protocol原因客户端不支持 4.1 新哈希解决改旧密码或升级客户端这个坑在 PHP 4 时代特别常见。PHP 的 mysql 扩展直到某个版本才支持 4.1 认证协议。临时解决是SET PASSWORD OLD_PASSWORD(xxx)长期解决是升级客户端库。如果应用代码里写死了连接方式改密码是最快的。注意改完密码后用新客户端连可能又报错因为新客户端默认发新协议遇到旧哈希会降级一般没问题但极老的客户端可能不认。4.4 现象数据目录权限报 Cant create/write to file原因datadir 属主不是 mysql 用户解决chown 后重试mysql_install_db和mysqld都会以--user指定的用户写datadir。如果datadir是 root 建的mysql 用户没写权限就报这个。解决就是chown -R mysql:mysql /opt/mysql/data然后确认父目录也有执行权限。注意不要用chmod 777MySQL 会拒绝启动认为权限太开放不安全。4.5 现象tar 解压报 Unexpected EOF原因包下载不完整解决校验大小后重新获取tar 包在传输过程中被截断是常事尤其是通过某些中间层下载。解压到一半报Unexpected EOF或gzip: stdin: unexpected end of file先ls -l看文件大小和预期是否一致再用gzip -t测试压缩包完整性。不完整就重新获取不要试图用tar --ignore-zeros强行解解出来的二进制大概率是坏的启动时报各种莫名其妙的错。5. 从能跑到能用字符集、备份与版本迁移的实操技巧5.1 字符集设置4.1 的 latin1 默认值与 utf8 的取舍4.1 默认字符集是latin1存中文会乱码。建库时显式指定utf8可以解决大部分问题但 4.1 的utf8是 3 字节版本不支持 emoji 和部分生僻字。如果业务只涉及常用汉字够用。设置方法CREATE DATABASE appdb DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; -- 4.1 支持 utf8 和 utf8_general_ci -- 不支持 utf8mb4别写服务端也可以在my.cnf里设default-character-setutf8但只影响新建库已有库要ALTER DATABASE改。连接时客户端也要设--default-character-setutf8否则服务端按 latin1 解析照样乱码。常见做法是服务端、库、表、连接四层都统一 utf8少一层都可能出问题。5.2 逻辑备份mysqldump 在 4.1 下的参数差异4.1 的mysqldump没有--single-transactionInnoDB 表备份会锁表。如果业务能停直接FLUSH TABLES WITH READ LOCK后拷贝数据目录是最快的。不能停就用mysqldump逐表导但要注意--opt默认开启会加锁。bin/mysqldump -uroot -S /tmp/mysql.sock \ --default-character-setutf8 \ --skip-extended-insert \ appdb appdb_backup.sql # --skip-extended-insert 每行一条 INSERT方便部分恢复 # 不加的话是一条 INSERT 多行恢复快但出错难定位备份出来的 SQL 在 5.x 上恢复通常没问题但 5.x 的mysqldump导出的文件在 4.1 上恢复可能报语法错因为 5.x 会加/*!40101 ... */之类的版本注释。跨版本迁移时用低版本的工具导高版本的工具恢复兼容性最好。5.3 迁移到新版本先升到 5.0 再往上的原因4.1 直接升 5.7 或 8.0 基本不可行系统表结构差异太大。稳妥路径是 4.1 → 5.0 → 5.5 → 5.7每步用mysql_upgrade修表。4.1 没有mysql_upgrade升到 5.0 后才有。迁移前先在测试环境跑一遍重点看mysql库的user、db、tables_priv表结构变化以及 SQL 模式差异。5.0 默认开启STRICT_TRANS_TABLES4.1 插入超长数据会截断5.0 直接报错应用层要改。从那以后我每次拿到这种老 tar 包都强制先跑一遍uname -m、ldd --version、file bin/mysqld三件套确认架构和依赖再动手解压。这套流程帮我省了至少三次「解压完启动不了、回头查半天」的返工。希望帮到你。本文还有配套的精品资源点击获取