Dynmap迁移到512px瓦片：公开验证与R2旧图像清理

我们对从 Cloudflare R2 分发地图图片的 Dynmap 配置进行了格式切换，并清理旧数据。范围是八台服务器、89 张地图。关键在于顺序：先确认新图片已公开显示，再删除旧图片。

迁移Dynmap瓦片前要比较什么

考虑512px瓦片时，应在相同渲染范围内比较普通图像与缩放图像，分别记录浏览请求和渲染写入。先列出旧prefix候选，确认新图像的公开显示和从世界重新渲染的恢复方法后，再决定是否删除。

R2：容量与操作次数的测量方法

限定渲染范围，分阶段切换

正式地图统一采用 512px 瓦片。需要补充渲染的 21 张地图，以公开中心为起点限制在半径 2,000 方块内。我们没有等待整个世界渲染完毕，切换期间仍保持日常更新。

同时改进了 R2 通信失败后的重试、写入失败时待更新内容的保留，以及缩放图片“确实不存在”和“读取出错”的区分。Dynmap fork PR #9 记录了重启后恢复缩放更新的修复。这些改动并不意味着 Cloudflare 自身不会发生故障。

1. 1 限定范围并生成新图 确定 512px 范围和渲染区域，在常规更新继续时分阶段生成新图像。
2. 2 审计公开图像与存储位置 分别检查普通与缩放图像、Web 资源、实时 JSON 和正式存储前缀。
3. 3 审计后清理旧数据 审计后删除旧图像与 hash。旧图像没有备份，需要时必须从世界重新渲染。

分别验证公开地图与存储

切换后，我们对 89 张公开地图各检查一张普通图片和一张缩放图片，共 178 张。除了确认图片为 512px，还检查了 Web 资源和实时 JSON 的更新。在 R2 侧，我们审计保存路径是否与 89 个正式地图前缀一致，并确认旧普通图与日间图的 192 个前缀已经清空。

之后才删除旧图片及旧 hash 文件，共 11,707,356 个对象、约 51.71 GB。旧图片内容没有备份，需要时必须从世界重新渲染。现行图片、世界、配置和 JAR 备份仍保留。最终审计确认旧图片、临时阶段数据和旧 hash 文件均未残留，而非只依据删除进程正常结束。

不要把容量变化等同于账单变化

在两个包含迁移工作的连续 24 小时区间中，成功的 PutObject 从 240,835 次降至 90,423 次。两个区间都包含迁移操作，因此不能据此推算正常运行时的降幅或月费。实际账单金额尚未核实。

类似迁移应分别查看 R2 操作量与存储量指标，再依次检查公开显示、现行图片和旧数据。删除之前，应先确定目标范围与恢复方法。