Campus-imaotai项目升级后出现502错误的排查与解决

问题背景

在使用Campus-imaotai项目时，用户从v1.0.12版本升级后遇到了前端502接口错误的问题。具体表现为前端无法显示验证码，且后端服务访问异常。这个问题看似简单，但实际上涉及到数据库权限、Spring Boot应用启动和Docker部署等多个技术层面的交互。

错误现象分析

用户最初报告的主要错误现象包括：

1. Docker部署的后端服务，前端访问时提示502接口错误
2. 验证码无法正常显示
3. 删除并重新部署后端容器后，8160端口也无法访问
4. 直接使用Java部署时，应用启动过程中抛出SQL异常

深入排查过程

数据库权限问题

从Java部署的日志中可以清晰地看到关键错误信息："Table 'i_shop' is read only"和"Table 'sys_resource' is read only"。这表明应用程序尝试对数据库表执行写操作时被拒绝，因为表被设置为只读状态。

进一步分析发现，这是由于MySQL配置参数innodb_force_recovery被设置为非零值导致的。这个参数通常用于数据库恢复场景，当设置为1-6的值时，InnoDB会进入不同程度的只读模式。而在生产环境中，这个参数必须设置为0才能保证正常的读写操作。

应用启动流程分析

Campus-imaotai项目在启动时会执行以下关键操作：

1. 初始化数据源并连接数据库
2. 执行表结构检查和数据初始化
3. 刷新商店信息(sys_resource)
4. 启动内嵌Tomcat服务

当数据库表处于只读状态时，第二步和第三步的操作会失败，导致整个应用启动失败。特别是以下关键操作受到了影响：

• truncate table i_shop
• truncate table sys_resource

这些操作是应用初始化的一部分，用于确保数据的一致性。

解决方案

正确的MySQL配置

确保MySQL配置文件中包含以下设置：

[mysqld]
innodb_force_recovery = 0

修改配置后需要重启MySQL服务使更改生效。

验证数据库权限

在解决问题后，建议执行以下验证步骤：

1. 使用MySQL客户端连接到数据库
2. 检查表的读写权限
3. 手动执行简单的INSERT和UPDATE语句测试

应用启动验证

在确保数据库配置正确后，重新启动应用时应观察以下正常日志：

1. 数据源成功初始化
2. 表结构检查和数据初始化完成
3. 内嵌Tomcat服务正常启动
4. 没有出现任何SQL异常

经验总结

这个案例给我们提供了几个重要的经验教训：

1. 数据库配置的重要性：即使是单个参数的设置也可能导致整个应用无法正常工作。
2. 日志分析的价值：详细的错误日志是诊断问题的关键，应该学会从中提取有用信息。
3. 启动顺序的理解：了解应用的启动流程有助于快速定位问题发生的阶段。
4. 环境一致性：开发、测试和生产环境的配置应该保持一致，避免因环境差异导致的问题。

对于使用Campus-imaotai项目的开发者来说，遇到类似问题时，首先应该检查数据库的可写性，确保所有必要的权限都已正确配置。同时，理解应用的初始化流程有助于快速定位和解决问题。