Closed lucaa closed 1 year ago
cf. @raphj sur https://github.com/DISIC/observatoire/issues/1191#issuecomment-1347910735
@lucaa @ldubost pour passer les avis existants vers le nouveau système de stockage, il y aura peut-être besoin de mettre une chaine vide dans les propriétés qui ont une valeur nulle, en particulier celles dont le type est Static List.
@ldubost @raphj s'il s'agit des propriétés multivaleur, je pense qu'une chaine vide n'est pas necessaire, il devrait suffir de ne pas mettre du tout des valeurs dans les tables de valeurs ( avis_aide
et avis_difficultes
).
S'il s'agit des autres colonnes (modalite, vote ?) je dirais que le résultat qu'on vise suite à la migration c'est d'obtenir la même chose que si on ajoutait un avis nouveau sans valeur pour ces propriétés, autrement dit d'être cohérents entre les avis existants et les nouveaux avis. Ça sera donc à tailler en fonction de ce que l'ajout d'un nouvel avis post custom mapping fait.
Le seul cas ou on peut vouloir altérer ce résultat (et donc mettre à jour le code d'ajout d'avis aussi pour garder la cohérence) est si la chaîne vide est nécessaire pour une optimisation de requête quelque part.
Complètement d'accord
Les scripts de migration sont préparés dans le repertoire aggregats:
Afin de migrer le processus suivant est proposé:
0/ Faire un snapshot de la VM 1/ Créer la table avis avec le script sql avis_migration_createtable.sql 2/ Utiliser migratebymonth.sh pour migrer un mois ou une année entière dans des moments de charges réduite (la nuit) (Durée 5mn par mois ou 1h par année) 3/ Activer le custom mapping et redémarrer XWiki, installer le code mis à jour côté observatoire 4/ Migrer le mois en cours (environ 5mn) 5/ Redémarrer XWiki
Les scripts d'effacement pourront être executer en Janvier. Il n'est pas clair si les scripts d'une durée de 5mn de l'étape 2 peuvent on non impacter les dépôts d'avis. Il est ainsi conseiller de les executer la nuit.
0/ Faire un snapshot de la VM 1/ Créer la table avis avec le script sql avis_migration_createtable.sql 2/ Utiliser migratebymonth.sh pour migrer un mois ou une année entière dans des moments de charges réduite (la nuit) > (Durée 5mn par mois ou 1h par année) 3/ Activer le custom mapping et redémarrer XWiki, installer le code mis à jour côté observatoire 4/ Migrer le mois en cours (environ 5mn) 5/ Redémarrer XWiki
reprise du plan, après discussion avec @ldubost :
1/ Créer la table avis en déployant le fichier de mapping fait pour #1191 (le nouveau jar) et la modification dans le fichier hibernate.cfg,xml 2/ Redémarrer XWiki pour que le mapping soit pris en compte et les tables créés (avis et tables liées) 3/ Utiliser migratebymonth.sh pour migrer un mois ou une année entière dans des moments de charges réduite (la nuit) (Durée 5mn par mois ou 1h par année) 4/ Faire un snapshot de la VM de la production 5/ Activer le custom mapping, installer le code mis à jour côté observatoire 6/ Redémarrer XWiki - optionnel, ce n'est pas nécessaire pour l'ajout du custom mapping 7/ Migrer le mois en cours (environ 5mn) 8/ Redémarrer XWiki
La stratégie et les outils sont préparés, la tâche reste ouverte jusqu'à l’exécution de la migration en production.
@ldubost j'ai ajouté une page pour des instructions plus précises pour exécuter la migration des avis https://github.com/DISIC/observatoire/wiki/%5B5.1%5D-Instructions-de-migration-des-avis-existants-vers-le-stockage-optimis%C3%A9 - y compris suppression. Ce qui m'intéresse dans cette doc est l'execution des scripts, comment les utiliser pour faire la migration - peux-tu compléter avec les informations?
Les instructions sont mises à jour et la migration est finalisée en production. La tâche est finie, je clos.
Le changement de méthode de stockage a été activé en production le 26/12/2022 à 15h00 et 42s.
À partir de cette date tout nouvel avis ajouté est stocké dans le nouveau stockage.
Suite à la mise en place du nouveau stockage optimisé des avis, tous les avis existants vont devoir être migrés vers le nouveau stockage optimisé.