Incidents antérieurs

Nous finalisons la bascule vers MySQL de GRP1, GRP2 et GRP4 le lundi 29 janvier 2024 à 21h heure de Paris.

Vous pouvez tester MySQL 8.0 avec vos identifiants actuels avant la bascule :

• vsdb01-mysql8.veryswing.com
• vsdb02-mysql8.veryswing.com
• vsdb04-mysql8.veryswing.com

Ce weekend nous avons pu stabiliser la situation et l'ensemble des environnements fonctionne normalement maintenant.

Vendredi 21h15, nous coupons la plateforme de secours pour basculer sur un tout nouvel ensemble technique qui ne posera plus de soucis.

Mise à jour à 7h30 heure de Paris, malgré une réinstallation complète du cluster dans la nuit, le système est à nouveau tombé et nous avons rebasculé sur l'équipement de secours. Comme hier, supprimez le cookie de session si vous avez un message d'erreur disant que l'application est indisponible.

Mise à jour à 1h30 heure de Paris, nous avons remis en route le cluster de production. Nous avons pu également remonter la réplication VSDB.

Ce soir, à partir de 21h, nous couperons tous les environnements du groupe 7 pour revenir sur le cluster de base de données de production. Depuis 10h, le service VSDB du groupe 7 est toujours accessible mais n'est plus répliqué en temps réel. La réplication sera remise en route demain en matinée une fois que la plateforme de productions sera à nouveau opérationnelle.

Mise à jour à 10h25 heure de Paris, nous avons du basculer sur la plateforme de secours. Si vous n'arrivez pas à vous connecter, supprimez vos cookies sur l'adresse de votre environnement. Nous allons chercher une solution au problème de cluster de production. Une fois le problème résolu, nous devrons couper pendant la nuit tous les environnements du groupe 7 pour remettre en route la plateforme de production.

Mise à jour à 9h50 heure de Paris, le cluster est toujours instable dès que nous laissons des connexions passer. Nous tentons un dernier test et si ce n'est pas concluant nous engageons une basculer vers un système de secours.

A 8h20 heure de Paris, le cluster semble à nouveau être tombé, nous regardons ce qu'il se passe.

Mise à jour à 7h55 heure de Paris, le cluster de base de données a été intégralement redémarré et fonctionne normalement. La synchronisation de tous les noeuds était bloquée. Nous cherchons la cause.

Depuis 7h15 heure de Paris, les environnements du groupe 7 sont inaccessibles, nous cherchons la cause du problème.

Tout est revenu à la normale, le cluster est au complet.

Mise à jour à 10h heure de Paris. Le load balancer était dysfonctionnel, il a été remis en route. Néanmoins un serveur du cluster n'était pas accessible, nous cherchons la cause.

Depuis 9h30 heure de Paris, les environnements du groupe 8 sont inaccessibles. Le cluster de base de données semble opérationnel, cela semble venir du répartiteur de charge qui se situe entre les serveurs applicatifs et le cluster de base de données.

La plateforme VSDB est à nouveau répliquée en temps réel, tout est revenu à la normale.

Le cluster est complètement reparti. La synchronisation VSDB sera remise en route dans la matinée du 10 janvier.

Les environnements sont accessibles, le serveur fonctionne sur 2 noeuds, nous remettrons en route le 3ème noeud dans la nuit. La plateforme VSDB est encore accessible mais n'est plus répliquée. Tout sera revenu à la normale d'ici demain matin.

Depuis 14h07 heure de Paris, tous les environnements du groupe 6 sont indisponibles. 2 noeuds du cluster de base de données se sont arrêtés, nous cherchons à redémarrer le cluster.

Nous avons réindexé tous les environnements sur une nouvelle plateforme, tout est revenu à la normale.

Le système d'indexation full text est indisponible depuis la coupure du serveur de cache hier dimanche 7 janvier 2024 à 12h50, le bascule réalisée n'a pas été effective sur la partie indexation. Nous cherchons une solution.

Nous avons pu remettre en route la plateforme en défaut. Nous sommes en surveillance pour comprendre et voir si cela se reproduit.

La plateforme VSDB des environnements du groupe 4 est inaccessible depuis 9h00 heure de Paris. Nous cherchons la cause du problème.

Vous pouvez accéder à la plateforme sous MySQL 8.0, qui est parfaitement fonctionnelle en changeant l'adresse du serveur : vsdb04-mysql8.veryswing.com en attendant que nous solutionnions le problème.

Changement de situation, nous avons finalement pu remettre en route l'ancienne plateforme en MySQL 5.7. Tout est reparti un peu après 23h heure de Paris.

Mise à jour à 17h30 heure de Paris, le plateforme doit être changée. Nous devons déployer sur une autre plateforme qui sera obligatoirement sous MySQL 8.0, cela devrait être disponible dans la soirée.

Le vendredi 22 décembre à 16h heure de Paris, la plateforme VSDB des environnements du groupe 1 s'est arrêtée de fonctionner. Nous recherchons la cause.