Description de l’incident
Les systèmes de réplication de données entre nos datacenter et vos hôtels ont subit une panne entrainant la désynchronisation des réservations provenant des channel manager. Cela a impacté les réservations reçues entre 14h38 et 16h.
Les dites réservations ne sont pas redescendues dans les hôtels ainsi que les segmentations/origines liées.
Cause de l’incident
Lors de la publication de la mise à jour, une nouvelle table a été créée dans la base de données, entrainant le recréation automatique des triggers de base de données, opération courante et fonctionnelle depuis des années.
Durant cette recréation le moteur de base de données a rencontré de nombreux Metadata lock qui ont provoqué un TimeOut d’exécution.
Le résultat est que certains triggers n’ont pas été recréé. L’opérateur, sur le publicateur a eu un message HTTP 504 Gateway TimeOut comme cela se produit des fois lorsque le publicateur envoie des notifications à Ms Teams. Il n’y a pas eu de message “Echec de la publication”. Le système de publication a tout de même permis le redémarrage des applications & services.
Après gestion de l’urgence & investigation, plusieurs possibilités ont pu provoquer cet incident :
- Certaines applications continuaient d’accéder à la base de données malgré le fait qu’aucune connexion base de données n'était active au lancement de la publication.
- La présence de très nombreuses contraintes de clefs étrangères sur les tables provoque plus de lock sur les tables
Intervention
- Arrêt manuel de tous les services
- Recréation de tous les triggers manuellement
- Mise à jour de la valeur d’un champ sur toutes les réservations concernées afin que des lignes de réplication soient générées pour que ces dites réservations redescendent dans les hôtels.
- Mise à jour du type de trigger sur ces lignes d’UPDATE en INSERT
- Envoi global de requête SQL chez tous nos clients pour que les lignes d'insertion de réservations passent au dessus des potentielles autres lignes qui potentiellement bloquaient la réplication Incoming
- Création, exécution d’un script SQL afin de récupérer la liste de tous les hôtels impactés par l’incident
Ce que nous allons mettre en place
- Vérification de la liste des applications arrêtées (appoffline) lors d’une publication nécessitant la recréation des triggers
- Retrait des doublons de user MySQL utilisés par plusieurs applications afin de pouvoir vérifier facilement dans la base de données quelle application exécute des requêtes
- Ajout, dans le publicateur, d'une fonction de vérification détaillée de la bonne existence de tous les triggers avant de laisser l'utilisateur qui publie redémarrer les services
- Etudier et implémenter si cela est possible le fait de ne recréer que les triggers qui doivent l'être plutôt que tous les triggers de toutes les tables. => Plus secure et plus performant.
- Afficher dans HelpDesk CRM Medialog la situation de la réplication des tables ReplicationIncomingOrdered et ReplicationOutgoingOrdered. Il s'agit là de la réplication des historiques d'éléments
A 1h34, la situation était stabilisée. Il subsistait une vingtaine d’hôtels dont le moteur de réplication était bloqué. Ils seront contacté par l'équipe Support dès ce matin.