# 生产滚动升级：ninca-common-component-organization（三实例）

**现场根目录（部署包）：**  
`/media/zebra/9e8fa357-7db6-4d70-88ed-d5de5a059a663/星河湾星中星/部署包/ninca_common_component_organization_01-ninca_common_component_organization`  

根下含 `bootstrap.properties`、`application-node.properties` 示例、`sql/`；三台各用子目录（本仓样例为 `…207` / `…208` / `…209`，与 `application-node.properties` 里 `component-organization-01`～`03` 对应）。

---

## 1. 为什么这样升级对终端用户额外风险小

三台是**滚动替换**：任意时刻总有两台在跑，上游 Consul/Ribbon 或负载均衡会把流量导向健康实例，不会像整机停机那样突然断服务。  
数据库脚本在 `**component-organization`** 库里**只执行一次**（维护窗口、由 DBA 或授权人在单点执行），避免三台各跑一遍弄乱数据。  
若新版本在某台不满意，可**换回停机前备份的旧 JAR**；涉及访客楼层等策略时，也可在库或配置侧**关闭/禁用策略**降低影响（与研发确认具体字段）。运行与构建均为 **JDK 8**。

---

## 2. 升级顺序（先库后应用）

1. **数据库（一次）**
  在 `**component-organization`** 上按变更单执行对应 DDL/DML（脚本与部署包 `sql/`、`docs/sql/` 同源说明一致）。**同一迁移禁止在三台应用机上重复执行。** 慎用含 `DROP TABLE` 的「全量安装」类脚本；生产优先增量脚本。迁移验证落库后再动应用。
2. **应用（逐台）**
  建议顺序如 **207 → 208 → 209**（或按现网约定）。**每台流程：** 若现场有 LB/摘流习惯可先摘该实例 → `stop.sh` 停进程 → **备份当前 Fat JAR**（如加 `.bak.日期`）→ 上传新 JAR（与发布说明 **SHA-256** 一致；三台用同一制品）→ **JDK 8** 下 `start.sh` 启动 → 本节第 3 步检查通过后再处理下一台。  
   保留各节点 `application-node.properties` 中的节点差异（Consul、instance-id、IP 等）；合并新版本键值时勿把数据源/Redis/注册中心改成测试环境。

---

## 3. 每台做完看什么（最多三条）

- **健康：** `http://<节点IP>:<management.port>/actuator/health`（路径以现场为准）应为 **UP**。  
- **日志：** `logs/` 下 info/error，无持续报错、无连库/注册中心失败风暴。  
- **冒烟：** 按变更单做只读或低风险接口抽查；若本次含访客楼层策略，用只读方式确认读取符合预期。

---

## 4. 不满意怎么撤回

**应用：** 停进程 → 把备份的 JAR 换回运行文件名 → 再起动并按上节三项看一眼。可只回滚有问题的那台。  
**库：** 优先与研发确认是否可通过关策略、改配置规避；若必须还原库，由 DBA 在评估窗口内操作，必要时先停写或停齐三台应用，避免双写分叉。

---

**备忘：** 三台最终应用包 **SHA-256 一致**；`sql/README.txt` 中对含 `DROP` 的脚本风险有说明，执行前核对变更单。