Migrer Dynmap vers des tuiles de 512px : contrôles publics et nettoyage R2

Nous avons changé le format des images d’un Dynmap distribué depuis Cloudflare R2, puis nettoyé les anciennes données. Le périmètre couvrait huit serveurs et 89 cartes. L’essentiel était l’ordre des opérations : vérifier publiquement les nouvelles images avant de supprimer les anciennes.

Que comparer avant de migrer les tuiles Dynmap

Comparez images normales et de zoom sur une même zone avant de choisir des tuiles de 512px. Distinguez requêtes de consultation et écritures de rendu. Inventoriez les anciens préfixes, puis décidez de leur suppression après vérification des images publiques et de leur régénération depuis le monde.

R2：Mesurer stockage et opérations

Migrer par étapes avec une zone de rendu limitée

Les cartes de production ont été uniformisées en tuiles de 512px. Pour les 21 cartes qui nécessitaient un rendu supplémentaire, nous avons limité la zone à un rayon de 2 000 blocs autour du centre public. Nous n’avons pas attendu la fin du rendu du monde entier ; les mises à jour ordinaires ont continué pendant la transition.

Nous avons également amélioré les nouvelles tentatives après une erreur de communication avec R2, la conservation des mises à jour en attente après un échec d’écriture, ainsi que la distinction entre une tuile de zoom absente et une erreur de lecture. La PR #9 du fork Dynmap décrit la reprise des mises à jour de zoom après redémarrage. Ces corrections ne suppriment pas les pannes possibles du côté de Cloudflare.

1. 1 Limiter la zone et produire de nouvelles tuiles Définir le périmètre 512px et la zone de rendu, puis produire les nouvelles images tout en poursuivant les mises à jour habituelles.
2. 2 Auditer les images publiques et le stockage Vérifier séparément les tuiles normales et zoomées, les ressources Web, le JSON en direct et les préfixes de stockage prévus.
3. 3 Nettoyer les anciennes données après audit Supprimer les anciennes images et leurs hash après audit. Sans sauvegarde, elles devront être rendues à nouveau depuis le monde si nécessaire.

Vérifier séparément l’affichage public et le stockage

Après la bascule, nous avons contrôlé une tuile normale et une tuile de zoom pour chacune des 89 cartes publiées, soit 178 images. Nous avons confirmé leur taille de 512px, puis examiné les ressources Web et les mises à jour du JSON en direct. Côté R2, nous avons vérifié que les chemins correspondaient aux 89 préfixes officiels et que 192 anciens préfixes d’images normales et diurnes étaient vides.

Ce n’est qu’ensuite que nous avons supprimé 11 707 356 objets d’images et de fichiers hash anciens, soit environ 51,71 Go. Le contenu des anciennes images n’a pas de sauvegarde ; il faudrait le rendre à nouveau à partir des mondes. Les images actuelles, les mondes et les sauvegardes de configuration et de JAR ont été conservés. Un audit final a confirmé l’absence d’anciennes images, de données de transition et de vieux fichiers hash, au-delà de la simple fin du processus de suppression.

Ne pas confondre stockage et facture

Sur deux fenêtres consécutives de 24 heures comprenant des travaux de migration, les PutObject réussis sont passés de 240 835 à 90 423. Ces deux fenêtres incluent la migration : elles ne mesurent ni le taux de réduction en fonctionnement normal ni l’écart de coût mensuel. Le montant facturé n’a pas été vérifié.

Pour une migration semblable, consultez séparément les indicateurs d’opérations et de stockage R2, puis vérifiez l’affichage public, les images actuelles et les anciennes données. Définissez le périmètre de suppression et la méthode de récupération avant tout effacement.