⬆️ 升级与回退

普通升级

1. 记录当前 InvSync、代理组件、MC、Java、物品插件/模组版本。
2. 备份持久化库、Redis 相关数据、世界和配置，确认备份可还原。
3. 停止登录，让所有玩家正常下线，等待保存完成，再正常停止所有相关节点。
4. 同一维护窗口更新所有主插件与代理组件；不要在生产混用不相容版本。
5. 比较新旧配置，保留旧 key，不擅自把驼峰 key 改成连字符。
6. 先限制登录，用测试账号验证，再开放。

v1 表升级到 v2

MySQL 当前主表为 invsync_player_data_v2，备份表为 invsync_player_backup_v2。旧表保留，玩家查询新表无记录时可从旧表惰性转换。

需要批量处理时，在维护环境执行：

/invsync compress
/invsync compressBackup

前者会跳过新表已有记录，后者处理旧备份。日志与表数量都要检查，不反复执行备份迁移造成重复记录。MongoDB 不使用这组 MySQL 表迁移命令。

Redis 与序列化

data-serializer 有 Gson/Kryo。更换方式需全网一致，并在所有写入停止后按实际键清理对应缓存。不要照抄过期教程里的 invsync:*，当前主数据键是 InvSync{prefix}:UUID，锁是 InvSyncLock{prefix}:UUID，预加载也有自己的频道和心跳键。

不提供全库清理命令

共享 Redis 不要执行 FLUSHALL / FLUSHDB。只有先确定库编号、前缀和完整 key 清单，备份后才处理本插件数据；不要在玩家在线时清锁。

物品格式升级

当前物品使用版本化二进制 NBT，并兼容部分历史 SNBT 解析。新格式能读取历史内容，不代表旧插件能读取新内容，更不代表新版 MC 物品可降级。

回退不是只换旧 JAR

升级后新表、新格式和新玩家进度可能与旧版不兼容。回退前先另存当前数据，再恢复对应版本的数据库、玩家档案、配置和插件组合。世界与玩家状态应保持一致，必要时请作者协助。

不承诺固定压缩百分比；数据占用取决于玩家和物品实际内容。