Linux WebLogic更新升级注意事项

在Linux环境下对Oracle WebLogic Server进行版本升级（如从12c升级到14c，或打补丁）是一项高风险操作。为了确保过程平稳，避免数据丢失和服务中断，请务必关注以下注意事项。

我将从准备阶段、升级方式选择、具体操作、回滚计划四个维度来详细说明。

一、 前期准备与检查 (最重要)

这是决定升级是否成功的关键，很多失败案例都是因为准备不足。

1. 仔细阅读官方兼容性文档

   • 认证矩阵 (Certification Matrix): 确认你的 Linux 版本（如 RHEL 7/8, SUSE, OEL）是否与目标 WebLogic 版本兼容。
   • JDK 兼容性: 新版本 WebLogic 通常要求特定的 JDK 版本。例如，WebLogic 14c 需要 JDK 11 或 17（推荐使用 GraalVM 或 HotSpot）。
   • 依赖库: 检查你的应用程序是否依赖了旧版本的 JAR 包，这些包可能在新版本 WebLogic 中被移除或替换。

2. 完全备份

   • 备份整个 Middleware Home: 包括 WebLogic 安装目录和域（Domain）目录。
   • 备份配置文件: 重点备份 config.xml, setDomainEnv.sh, startWebLogic.sh 以及自定义的 JDBC、JMS 配置。
   • 备份应用部署包: 即使它们在服务器上，也建议单独存档。

3. 环境检查

   • 磁盘空间: 确保有足够的空间。升级通常需要解压新安装包，并且可能使日志和临时文件增大。建议预留原安装目录大小 1.5 倍以上空间。
   • 文件句柄与内存: 检查 Linux 的 ulimit 设置，确保打开文件数（nofile）和进程数（nproc）足够，防止启动时报错。
   • 端口占用: 确保新版本安装或升级过程中需要的端口没有被占用。

4. 应用代码兼容性测试

   • Java EE 到 Jakarta EE: 如果是从 WebLogic 12c (Java EE 8) 升级到 14c (Jakarta EE 9/10)，注意包名从 javax.* 变更为 jakarta.*。这是最大的坑，可能直接导致应用无法启动。
   • Deprecated API: 检查代码是否使用了已废弃的 WebLogic API。

二、 选择合适的升级策略

WebLogic 升级通常有两种主要方式，推荐 B 方式（新建域迁移）。

A. 原地升级 (In-place Upgrade)

• 描述: 使用 Oracle 的 Upgrade Assistant 工具在原有目录上直接升级。
• 优点: 配置保留相对完整。
• 缺点 (风险): 风险极高。一旦失败，回滚困难；容易留下冗余的旧文件导致环境臃肿；如果是跨大版本（如12c到14c），Oracle 官方可能不支持这种直接升级。
• 适用: 仅用于小版本补丁（如 12.2.1.3 到 12.2.1.4）且无法重建环境的情况。

B. 迁移升级 (Side-by-side / New Installation) —— 推荐

• 描述: 在服务器上安装一个新的 WebLogic 版本，创建一个全新的域，然后将旧域的配置和应用迁移过去。
• 优点:
  • 安全: 旧环境保留完好，随时可以切回。
  • 干净: 没有旧版本的垃圾文件。
  • 可控: 可以逐步迁移配置，排查问题。
• 缺点: 操作步骤较多，需要重新配置 NodeManager 和服务器启动脚本。
• 步骤简述:
  1. 安装新版本 JDK。
  2. 安装新版本 WebLogic。
  3. 使用 Configuration Wizard 创建新域（Domain）。
  4. 拷贝旧域的应用包（War/Ear）到新域。
  5. 手动比对并迁移数据源、JMS、安全配置等（不要直接覆盖 config.xml）。

三、 Linux 系统层面的特殊注意事项

1. 用户与权限 (User & Permissions)

   • 建议使用专门的用户（如 weblogic 或 oracle）运行，不要使用 root。
   • 升级后注意检查文件的属主（Owner）。如果用了 root 解压安装包，可能导致启动失败。使用 chown -R 修正权限。

2. 环境变量冲突

   • PATH 和 JAVA_HOME: 新版和旧版可能使用不同的 JDK。确保 $JAVA_HOME 指向正确的新 JDK，且 $PATH 中优先找到新 JDK 的 java 命令。
   • 清理旧环境变量: 检查 /etc/profile, ~/.bash_profile, 以及 WebLogic 的 setDomainEnv.sh，确保没有残留的旧路径。

3. NodeManager 配置

   • 如果你使用 NodeManager 管理服务器，新版本安装后需要重新配置 NodeManager。
   • 注意 nodemanager.properties 中的 ListenAddress 和 ListenPort 设置。

4. 防火墙与 SELinux

   • 如果开启了 SELinux (Enforcing mode)，WebLogic 可能会因为权限不足无法绑定端口或读取文件。升级前建议临时设置为 Permissive (setenforce 0) 进行测试。
   • 确认 Linux 防火墙（firewalld/iptables）是否放行了 WebLogic 的管理端口（如 7001）和应用端口（如 8001）。

四、 回滚计划 (Rollback Plan)

在做任何变更前，必须有“一键回退”的能力。

1. 保留旧环境: 如果采用迁移升级，旧服务器不要马上卸载。保持运行或至少文件保留。
2. 修改软链接: 如果使用软链接指向 WebLogic 主目录，只需将链接指回旧版本即可。
3. 快照: 如果是虚拟机（VMware/KVM），升级前打一个快照。如果是物理机，确保备份是可恢复的。

五、 具体升级操作 Checklist (以迁移升级为例)

1. [ ] 停止服务: 停止受管服务器 -> 停止 AdminServer -> 停止 NodeManager。
2. [ ] 备份: 备份旧域和安装目录。
3. [ ] 安装新JDK: 解压 JDK 11/17 到新目录。
4. [ ] 安装新WebLogic: 运行 java -jar fmw_xxx.jar (静默或图形化)。
5. [ ] 创建新域: 运行 config.sh。
6. [ ] 同步配置:
   • 复制 security 目录（如果要保留 boot.properties）。
   • 复制 bin 目录下的自定义脚本（注意修改 JAVA_HOME 路径）。
   • 在控制台重新配置数据源（建议重新建，不要直接改 XML）。
7. [ ] 部署应用: 部署应用包，如果版本不兼容（如 javax 问题），需要开发介入修改代码。
8. [ ] 启动测试:
   • 启动 AdminServer，查看日志无报错。
   • 启动受管服务器。
   • 进行冒烟测试（访问页面，测试数据库连接）。
9. [ ] 清理: 确认稳定后，清理旧版本安装文件和日志。

常见错误避坑

• 错误: Unsupported major.minor version
  • 原因: JDK 版本不对。比如用 JDK 8 启动需要 JDK 11 的 WebLogic 14c。
• 错误: 启动慢，卡在随机数中。
  • 解决: 在 JAVA_OPTIONS 中加入 -Djava.security.egd=file:/dev/./urandom。
• 错误: 中文乱码。
  • 解决: 确认 Linux 系统语言环境 (locale)，并在启动参数中加入 -Dfile.encoding=UTF-8。

建议: 在测试环境完全模拟上述流程至少三次，确认无误后再在生产环境操作。