Cette page vise à tirer expérience des releases précédentes en listant les pièges à éviter

Anticiper le temps

Maj qui implique un téléchargement externe des données

La maj du module maps ou clip_gshhs implique un rapatriement des données quand elles ne sont pas présentes (téléchargement d'un fichier de 100Mo de gshhs2) Il faut donner les opérations manuelles pour by passer ce téléchargement.

Se méfier des suppressions/créations lourdes en base

Certaines opérations en base peuvent être longue sur la prod. Il faut se méfier :

• du temps que ça prend
• des effets collatéraux de la réplication

Penser aux données générées à l'extérieur des procédures de déploiement

Cela renvoie partiellement aux téléchargements, mais de manière plus spécifiques, aux données de base pour les tiles générées par vlmtools/clip_gshhs. Ces fichiers doivent être générés en amont de la release et MISE à DISPO SUR TESTING.

Anticiper les bugs

Création à postériori d'indexes uniques

Il faut dans ce cas prévoir en amont de l'upgrade de base proprement dit une vérification d'unicité par une requête SQL. Ca évite de gérer la crise pendant la release !

Prévoir les vérifications

• le lancement unitaire d'un binaire pour vérifier qu'il est utilisable
• la taille des espaces disque
• des comptages SQL en cas d'opérations lourdes

Prévoir les sauvegardes

Systématiquement, dans le doute...

Gérer les bugs

Mettre une page d'indispo si possible

Lors de mise en oeuvre de maintenance longue ou en cas de souci persistant. (ticket #534)

Savoir restaurer une sauvegarde

Point pour mémoire

Savoir étendre un file system

• Etendre un LV : lvextend

Pour étendre "de 10 Go" : -L+10G
Pour mettre "à 20Go" : -L20G

• Puis engazonner après la nouvelle clôture pour profiter de la nouvelle parcelle ensuite : resize2fs

• Exemple :

lvextend -L 20G /dev/vgdata/lv_mysqllog
resize2fs /dev/vgdata/lv_mysqllog