3.7 KiB
3.7 KiB
两集合迁移说明
迁移目标为 activityConfigs 和 goldMinerPlayerPeriods。运行代码前应完成已有环境的数据迁移；仅上传新版代码会导致旧配置和未嵌入的资格不可见。
脚本：migrate.cjs，由有数据库权限的维护人员在 mongosh 中执行，不是云函数，也不属于客户端接口。脚本默认只读预检，明确 apply=true 才写入，始终不删除旧集合、不修改 users 或 order。
迁移范围
| 来源 | 目标 |
|---|---|
| goldMinerConfigs / gold_miner_configs | activityConfigs，activityId=goldMiner 的版本记录 |
| goldMinerPeriods / gold_miner_periods | activityConfigs 的 control 记录，保留已冻结配置与停购开关 |
| cloudRiseConfig | activityConfigs，activityId=cloudRise 的版本记录 |
| goldMinerPlayerPeriods / gold_miner_player_periods | goldMinerPlayerPeriods，补齐合并后的字段 |
| goldMinerEntitlements / gold_miner_entitlements | 对应玩家期的 entitlement；未开期的 reserved 资格可以创建轻量玩家期记录 |
| goldMinerRewardGrants / gold_miner_reward_grants | 核对原 tasks 内的 grantId、奖励、发货状态，保持权威记录不变 |
| goldMinerSettlements / gold_miner_settlements | 玩家期的稳定 settlementId 和原展示确认时间 |
| goldMinerJobCursors / gold_miner_job_cursors | 不再使用，无需迁移；待处理记录按业务状态重新扫描 |
脚本保留玩家期 _id、grantId、settlementId、原 configSnapshot 和已领取状态。若旧奖励与玩家记录不一致、目标配置冲突或已解锁玩家缺少资格来源，预检直接失败，需要核对数据后再继续，不能用“未领取”覆盖历史已发记录。
百人赛旧配置版本命名为 legacy:<periodId>，将旧配置当作已经发布的版本，publishedAt 固定为 startsAt-1（这是兼容旧系统没有发布时间的迁移约定，不是历史审计时间）；忽略旧 enabled/status，保留当前时间窗口、奖池和 durationHours，缺省时按原有默认值处理。已有 users.cloudRiseState 不修改。旧的“修改当前期配置”管理方式迁移后停止使用。
执行步骤
- 备份相关集合，安排维护窗口，停止活动写入、支付回调处理和后台定时任务。确保支付平台回调后续能重试恢复。
- 在 mongosh 中选中正确的目标数据库。修改下面脚本绝对路径，先预检：
const { migrate } = require('C:/Users/NK/Desktop/workspace/server/laf-cloud/functions/activityConfig/migrate.cjs');
await migrate(db, { apply: false });
- 预检返回 dryRun=true、记录数量和拟写入条数。核对环境、备份及结果后执行：
await migrate(db, { apply: true });
- 在仍然停止写入的维护窗口中重复预检，正常应返回 writes=0；若脚本中途故障，可以在同一窗口内重跑。不得在业务已经恢复、新记录继续变化后把旧集合再次覆盖迁入。
- 部署公共模块和两个活动的新版函数。分别执行
/goldMiner/admin、/cloudRise/cloudRiseAdmin的 setup_indexes；新版索引只建立在公共配置和玩家期集合以及原有业务集合，不创建被移除的集合。 - 核对每种 activityId 的配置、玩家各期进度、原任务状态、下一期 reserved 资格、补发查询和原订单关联，再恢复入口、回调和每分钟任务。
迁移先完成全部源数据检查，再执行写入；写入阶段不是跨集合事务，因此必须停止并发写入。脚本会读取源集合进行核对，应先在测试库评估数据规模和执行资源。迁移完成前不要删除旧集合；本仓库不提供自动删表操作。