Seal Plugins

外观

SealAttributes V1 升级、备份与回滚 ​

1. 适用范围 ​

1.0.0 是第一版本地交付候选，没有更早的稳定 SealAttributes 版本可做原地升级。本文规定后续 V1 补丁升级和故障回退的共同流程。不要使用 Bukkit /reload、PlugMan 或同类热替换工具。

2. 升级前 ​

  1. 安排维护窗口并正常停止服务器，确认控制台出现 storage stopped: drained=true；
  2. 备份 plugins/SealAttributes/，包括八份业务配置和 SQLite 文件；
  3. MySQL 使用组织现有物理备份，或执行带 --single-transaction 的逻辑备份并验证可恢复；
  4. 记录旧 JAR 文件名、SHA-256、数据库 schema、服务端构建、Java 版本和所有软依赖版本；
  5. 在隔离副本用真实数据恢复备份，再执行一次启动、登录、战斗、保存和停服验收。

只替换运行 JAR，不要把 sealattributes-api、sealattributes-adapters 子模块、P9/P10 探针或文档 JAR 放进服务器 plugins/。所有已启用的适配代码都合并在主运行 JAR 中。

3. 数据库迁移 ​

插件启动时按顺序迁移 schema；未来 schema 高于当前代码支持版本时会拒绝启动，不会猜测降级。MySQL 需要备份确认的迁移必须先完成并验证备份，再临时按版本说明开启确认项。禁止手工改 sa_schema_version 绕过检查。

1.0.8 把 schema 1 升到 schema 2，新增通用 sa_resource_state 表。SQLite 会在迁移前自动生成并 完整性检查备份；MySQL 必须先完成外部备份并按配置确认。回滚到只理解 schema 1 的 JAR 时，必须同时恢复 升级前数据库，不能只删除新表或手改版本号。

4. 回滚 ​

  1. 停止新版本，保存完整失败日志、JAR SHA 和数据库副本；
  2. 如果新版本没有执行 schema 变化，可恢复旧 JAR 和旧配置副本；
  3. 如果执行过 schema 或数据语义变化，必须同时恢复升级前数据库备份，不能只换回旧 JAR；
  4. 使用与备份一致的服务端、Java 和软依赖版本启动隔离验证；
  5. 验证登录 READY、生命、永久来源、战斗、检查点和 drained=true 后再恢复业务流量。

SQLite 文件复制必须在服务器停止后进行；复制正在写入的数据库不构成可靠备份。MySQL 回滚前先隔离 写流量，避免新旧节点同时写同一 schema。