Prise en charge de MySQL 5.7, considéré comme obsolète

Service hérité en cours de retrait. MySQL 5.7 n'est plus pris en charge par l'éditeur et ne reçoit plus de correctifs de sécurité généraux. Il n'est pas proposé pour les nouvelles inscriptions, ventes, développements ni pour de nouvelles bases de données.

Les bases de données héritées qui dépendent encore de MySQL 5.7 doivent être migrées vers une version de base de données actuellement prise en charge par le service. La date limite pour terminer la migration est le 31 décembre 2026 ; l'accès hérité ne doit pas être considéré comme une solution permanente.

MySQL 5.7 a atteint la fin de ses mises à jour publiques en octobre 2023 ; vous pouvez consulter l'avis de l'éditeur. Le calendrier de retrait du service Hostsuar est différent de celui de l'éditeur.

Plan de migration

1. Inventoriez l'application, ses connecteurs, jeux de caractères, collations, types de données et requêtes incompatibles.
2. Mettez d'abord à jour l'application, le framework, les pilotes et les extensions vers des versions qui prennent en charge une base de données supportée.
3. Exportez la base, importez-la dans un environnement de staging avec la version supportée choisie et corrigez les incompatibilités sans modifier du code tiers de manière improvisée.
4. Testez l'intégrité, l'écriture, les recherches, les tâches planifiées, les sauvegardes et la restauration. Dans le clone, désactivez les e-mails, paiements, webhooks et tâches qui pourraient dupliquer des actions de la production.
5. Planifiez une fenêtre de changement, effectuez une sauvegarde finale, migrez et conservez un plan de retour arrière limité dans le temps.

Vérifiez dans cPanel ou auprès de l'assistance quelle version de base de données supportée est disponible sur votre service avant de préparer la destination.

Contrôles temporaires obligatoires

• Confirmez auprès de l'assistance les restrictions réseau de l'environnement hérité et utilisez uniquement les accès autorisés. Ne publiez pas une installation indépendante de phpMyAdmin pour contourner ces restrictions.
• Limitez l'accès par réseau et par utilisateur au strict nécessaire, utilisez des identifiants uniques et changez tout secret partagé.
• N'ajoutez pas de nouvelles applications, données ou fonctionnalités à l'environnement hérité.
• Conservez des sauvegardes externes vérifiées, testez leur restauration et surveillez les accès, les erreurs et les modifications.
• Vérifiez quelles données l'application doit conserver et évitez de créer de nouvelles copies sans contrôle. Si vous avez besoin de restrictions réseau supplémentaires, coordonnez-les avec l'assistance : le pare-feu du nœud ne s'administre pas depuis votre compte.

Contactez l'assistance pour confirmer l'origine, la destination supportée et une date de migration dans le délai. Une exception temporaire ne fait que réduire l'exposition ; elle ne rétablit pas le support et ne corrige pas les vulnérabilités de MySQL 5.7.

Vérifier le changement

Vérifiez la version depuis la connexion qu'utilise réellement l'application, et pas seulement depuis un autre accès phpMyAdmin. Après le changement, examinez les erreurs, les enregistrements récents et les tâches planifiées. S'il faut revenir à l'origine, arrêtez les écritures et décidez comment conserver les données créées dans la destination ; changer uniquement les identifiants peut faire perdre ces opérations.