保康智慧餐厅与进销存共机部署过程

整理日期：2026年10月16日。适用服务器：192.168.1.211。操作记录主要发生于2026年10月14日。

阅读范围

这份文档记录本次真实部署经过，并给出下一次共机部署顺序。历史故障处理不是可重复执行的安装脚本。原始 localV1.0.0 的20.03环境包，不应原样或仅放开版本检查后运行在已有业务的24.03服务器上。

本次没有远程读取服务器。事实来自对话中的终端输出、截图、部署文档及已检查的包；229、117、25包的结构只依据服务器展示结果，未在本地完整复核。最后业务状态见《部署结果》，不能以本文中的历史成功替代当前验收。

一 交付物和项目对应关系

代码包的编号不是数据库版本号。SQL与229功能是否齐全需要核对迁移记录，不能仅按文件号推断。原static.zip文档SHA256为c4071b09eb959b475ffb54b5a443ed1b16d8018cf49a7963cf0619f0520eac6d；本次最终使用文件的校验执行结果未留存。

二 本次部署经过

1 上传与系统检查

最初目标提及192.168.5.44，现场执行最终为192.168.1.211。192.168.5.45是外部食安服务，不能批量替换它的地址。Windows本机负责scp/ssh；登录后的Linux提示符负责服务器命令。

# Windows本机，文件位于当前文件夹时
scp ".\zhct_229.tgz" root@192.168.1.211:/root/
scp ".\aizhct_117.tgz" root@192.168.1.211:/root/
scp ".\store_25.tgz" root@192.168.1.211:/root/
scp ".\static.zip" root@192.168.1.211:/root/
ssh root@192.168.1.211

现场系统openEuler24.03 LTS-SP4 x86_64，约32GB内存。/home为独立LVM文件系统，约830GB；通过/home/workspace绑定到/workspace。独立文件系统不等于必须是第二块物理盘；不能照抄示例/dev/vdb进行格式化。

2 环境安装与原业务受影响

原脚本首先拒绝24.03。随后放开系统判断、使用现有24.03软件源后继续安装，安装及调整后的环境验收曾通过。

安装日志明确显示卸载系统MySQL8.0.46及其依赖，另行安装MySQL5.6.51。安装器还写入/etc/systemd/system/nginx.service，使nginx服务优先启动/usr/local/nginx，覆盖了原发行版服务的优先级。Redis使用新程序和认证配置，进销存原密码不再匹配。

因此，“环境验收通过”只表示脚本检查的组件通过，不代表共享服务器原业务兼容性通过。此前按空服务器前提给出的安装指导没有充分保护已有服务，是本次需要修正的部署方法。

3 手动放置业务代码

主项目目录：/workspace/wwwroot/zhct_local/project。AI API目录：/workspace/wwwroot/aizhct_local/project。路径中的local沿用目录命名，实际商户仍是bkzx，不要求两者同名。

# 仅用于首次部署、目标目录为空；更新不能覆盖执行
mkdir -p /workspace/wwwroot/zhct_local/project
tar -xzf /root/zhct_229.tgz -C /workspace/wwwroot/zhct_local/project
mkdir -p /workspace/wwwroot/aizhct_local/project
tar -xzf /root/aizhct_117.tgz -C /workspace/wwwroot/aizhct_local/project
chown -R www:www /workspace/wwwroot/zhct_local/project /workspace/wwwroot/aizhct_local/project

store25应以index.html/js/css为包根解压到主站public/store；先检查tar目录再解压，避免dist/store多套一层。public目录是Nginx文档根，不能把整个PHP仓库作为网站根。

4 数据初始化与登录排障

229包现场包含db/init/local_v1.0.0下两份SQL。查找未发现显式CREATE DATABASE、DROP DATABASE、USE语句后，分别导入zhct_bkzx和aizhct_bkzx。结果256张表、163张表；业务账号wwwweb曾成功查询配置表，返回75、9条。

最初登录500的PHP错误日志显示队列Redis NOAUTH；补齐前厅Redis密码后，应用日志显露MySQL1045。随后修改前厅连接密码，现场截图出现已登录业务页面。错误处理过程体现：日志中的异常上报队列错误可能遮住原始业务异常，需要每次只看最新请求。

没有重设系统admin密码，也不应因500重导业务库。敏感口令不写入本文。

5 图片与网站端口

static.zip解压到主站public后形成static/upload。图片请求仍指向127.0.0.1，浏览器实际访问Windows本机IIS；指导将ydy_config.ossHost改为http://192.168.1.211，迁到4200后需为http://192.168.1.211:4200。图片最终HTTP200及完整展示待验。

前厅由80改4200；根路径跳转/dist/#/login。AI API保持127.0.0.1:81，由主站/aizhct/转发。截图中部分网站/微信回调仍为8080，需逐项修正，不能全局替换端口。

6 Nginx拆分

发行版Nginx程序和配置保留。停止两套进程后，将LNMP的/etc/systemd/system/nginx.service移为zhct-nginx.service，daemon-reload恢复发行版nginx.service。我们的默认站点由80移至本机18080，前厅4200、AI本机81；进销存原Nginx8000、9000。

已见两个服务active，各自端口监听，4200/dist/及8000/均返回200。此时进销存后端8670/8682仍不可用，Nginx共存不是业务恢复终点。

7 MySQL恢复与隔离

原/var/lib/mysql/hcgj_prod仍存在，程序和服务文件已被卸载。停止状态下复制整个原数据目录到/home/workspace/mysql8-recovery-20261014-190015/mysql，252MB；只按目录大小不能替代内容完整性验证，未收到diff最终结果。

我们的MySQL5.6改用/etc/zhct-mysql56.cnf、3307、/tmp/zhct-mysql56.sock、/usr/local/mysql/var。修改mysql.service及本机管理凭据连接参数后，查询确认版本5.6.51、3307、独立目录。

恢复/etc/my.cnf.rpmsave，阻止自动启动后通过DNF安装同版本8.0.46-1.oe2403sp4。确认原数据目录与独立Socket后启动mysqld，日志ready for connections、3306监听，enable成功。原数据内容和应用原凭据是否完整可用仍需业务查询验证。

禁止MySQL5.6读取MySQL8目录；禁止initialize、删除ibdata/mysql.ibd/redo文件、创建空hcgj_prod掩盖恢复问题。

8 Redis隔离与进销存重启

进销存JAR内application-local.yml显示redis及redis2为127.0.0.1:6379、DB10、密码认证。Java由Supervisor管理，进程RUNNING但无接口监听；日志有Redis invalid password和数据库连接异常。

6379停止后备份/etc/redis.conf、服务文件和/var/lib/redis到/home/workspace/redis-recovery-20261014-192908，数据244KB，diff无差异；再启动。此备份为LNMP安装之后的状态，不是进销存原Redis配置或原完整数据证明。

从当前配置创建zhct-redis：127.0.0.1:6380、/var/lib/zhct-redis、/etc/zhct-redis.conf，沿用我们的密码，PONG验证成功。新实例为空，旧会话/队列没有迁移。

指导前厅和AI切换Redis6380及MySQL3307。AI段落已见端口正确；前厅Redis6380已见，主库和ai_zhct的3307曾缺失，后续完成证据未收到。用户修改6379认证并重启redis；两个Redisactive，Supervisor重启portal/merchant开始执行，但8670/8682监听和登录成功未留证。

9 重启后网页不可达

重启后/workspace挂载正常、zhct-nginx已启动，本机4200返回200，外部电脑192.168.1.238能ping服务器，但4200和8000超时。iptables处于active，INPUT只有已建立连接、ICMP、loopback、SSH22允许，末尾REJECT；firewalld inactive不等于没有过滤。

最后给出的修复是仅允许192.168.1.0/24访问4200/8000/9000，并保存至/etc/sysconfig/iptables。最后截图仍未出现新增规则；放行执行、网页恢复、持久化和再次重启验收都未确认。

三 下一次共机部署的正确顺序

第一道门禁 先确定边界

收集两套系统负责人、维护窗口、依赖版本、访问网段、业务备份恢复方案。服务器不能因“新采购”就视为无业务。先通过只读盘点确认进程、端口、包、服务和目录。

cat /etc/os-release
ip -br addr
lsblk -f
findmnt -T /workspace
ss -lntp
systemctl list-units --type=service --state=running --no-pager
systemctl list-unit-files --type=service
ps -eo pid,ppid,args
rpm -qa | sort
systemctl cat nginx mysql mysqld redis supervisor --no-pager
iptables-save

输出可能含凭据，留在root受控目录，脱敏后才能交付。检查容器及其他端口管理程序也属于盘点范围。

第二道门禁 先备份和冻结端口

原业务配置、systemd覆盖文件、Supervisor配置和数据库都要备份；运行中的数据库应做一致性备份，物理目录拷贝必须停对应实例或使用有效快照。保留原二进制版本和可恢复的软件包。

本次建议沿用：进销存8000/9000、后端8670/8682/8600、MySQL3306、Redis6379；前厅4200、AI本机81、MySQL3307、Redis本机6380。若现场已有占用，先重新分配，不直接套表。

第三道门禁 选择安装方式

优先使用两套独立虚拟机；同机必须部署时，使用经过验证的独立容器栈或独立前缀的原生组件。容器不能凭空解决共享卷、端口和数据库版本问题；本项目尚未提供经过验证的24.03共机一键包。

若采用当前原生方案，事先构建已适配24.03的环境包，审查全部嵌套安装器和RPM事务。不允许卸载已有mysql/redis/nginx，不允许重写它们的全局服务入口。只修改操作系统检查不是兼容性验证。旧20.03脚本仅作参考，不作为下次生产命令。

第四道门禁 全部资源从第一天隔离

独立Nginx服务zhct-nginx，独立MySQL配置/端口/Socket/目录，独立Redis服务zhct-redis/配置/端口/目录。mysql服务名是本次遗留，可保留但必须标明5.6；下次可从一开始使用zhct-mysql56，不能现场盲目重命名现有服务。

首次解压到暂存目录，校验SHA256、包根、业务标识、依赖和SQL。保留prod/zhct_bkzx与AI prodaizhct_bkzx，填入新实例3307/6380；食安外部服务按原合同保持。

第五道门禁 先恢复依赖再启业务

先验证数据库版本/目录/表与读写权限、Redis认证，再启动PHP和队列，最后加载Nginx。初始化仅指向本项目新空库；不运行reset-database覆盖现有数据。SQL名称不是兼容性保证，要审查完整迁移顺序和回滚。

图片单独校验与解压；验证实际图片URL为4200同源入口。ai_store BASE_API、前厅ai_api_host、回调URL、上传大小、任务队列都需联测。

第六道门禁 两套系统与重启双验收

先跑进销存基线再跑新系统，部署后两套重复验收：登录、主业务、图片上传/展示、后台任务、错误日志。服务enabled只能证明开机策略，active只能证明进程状态。

确认/workspace挂载依赖、数据库启动等待与应用重试机制，按访问网段放行网页端口并保存。完成维护窗口内重启，验证远程电脑访问、两套登录及后台任务，再交付。未通过不能标记部署完成。

四 发布和回滚原则

代码发布先备份、暂存、检查再切换；禁止原单项目下载脚本覆盖当前商户配置。数据库回滚必须明确新写入数据如何保留，旧物理备份不能直接盖回运行实例。服务故障只操作所属服务，禁止killall nginx、lnmp stop、重跑原安装器、iptables -F。凭据不得复制进普通交付包。