Incident20100314

Le mieux est de lire le forum.

#En résumé :

• Le 14/03 à 0h UTC, le serveur principal de Vlm (celui qui calcule vos positions) est "tombé" (pas trop bas, je vous rassure).

• Au redémarrage (à 13h30 UTC), votre déplacement et donc votre position a donc été calculée sur une vacation de 13h30. Les bateaux ont fait un "tout droit" pendant 13h30, en tenant compte de leur cap (qu'il vienne d'un pilote, d'une allure ou du barreur) et de la météo ou moment du calcul. Chacun a pu se rendre compte que ce n'était pas l'idéal, mais aussi que les situations pouvaient varier et que certains pouvaient trouver cela à leur avantage.

• à 14h30 UTC, VLM a été "inhibé" a nouveau afin de se donner un délai de réflexion.

• Le problème vient de la durée sans compilation

• Le redémarrage du serveur réactive les compilations moteur, d'ou une énorme vac problèmatique

  • Action : peut on éviter ça ?

• les difficultés pour la reprise se sont concentrées sur le rédémarrage de la 777 (annulation de la vac intermédiaire).

  • Action : peut on faire un script générique / une interface d'admin pour ça ? C'est le ticket #442.

• un outil comme http://piratepad.net est très utile pour synchroniser l'expérience de tous pour la résolution de l'incident. Et ça permet de produire facilement cette page.

Vérifier que la météo de 22h30 TU est chargée OK

SQL

Partie sans problème

# rescheduled races id : 20100312, 20100314
# remettre les courses avec les bonnes dates et dans le bon état
# Question (spf) : lors du "vidage" des 2 courses, on remet a zero la liste des participants, ou on laisse l'actuelle ? (ou on remet aussi ceux qui ont abandonne)
# R (paparazzia) : On laisse l'actuelle. On laisse tout ceux qui sont engagé au moment du rescheduling.

UPDATE races SET started deptime+604800, closetime 20100312 ;
UPDATE races SET started deptime+604800, closetime 20100314 ;

# vider la table position pour ces courses

DELETE FROM histpos WHERE race IN ( 20100312, 20100314);
DELETE FROM positions WHERE race IN ( 20100312, 20100314);

#Vider les résultats
delete from races_results where idraces in ( 20100312, 20100314);
delete from waypoint_crossing where idraces in ( 20100312, 20100314);

#Mettre tout le monde bout au vent.
update users set pilotmode=2, pilotparameter=0 where engaged in ( 20100312, 20100314);

# Mettre les races instructions à jour (mention de l'opération)
INSERT INTO races_instructions ( idraces, instructions, flag)
values (20100312, "Course reprogrammée. Cf. les détails sur le forum." , 7);
INSERT INTO races_instructions ( idraces, instructions, flag)
values (20100314, "Course reprogrammée. Cf. les détails sur le forum." , 7);

# Special case : 777 (idrace = 20100216)
# Vidage des positions après le plantage : 1268528400

# Il faut gérer les traces de ceux qui sont arrivés ID = 7079, 3269, 15806, 5122, 15692, 3000,15448,4196

DELETE FROM histpos WHERE race = 20100216 AND time > 1268524860 AND idusers NOT IN ( 7079, 3269, 15806, 5122, 15692, 3000,15448,4196) ;
DELETE FROM positions WHERE race = 20100216 AND time > 1268524860 AND idusers NOT IN ( 7079, 3269, 15806, 5122, 15692, 3000,15448,4196) ;

Première option essayée pour la 777 : mise à jour du timestamp pour que la première vac soit d'une durée normale

# Timestamp du moment du plantage (à 2 minutes près, c'est minuit), donc on peut repartir sur les positions de 0h00, en assurant le coup, on s'appuie sur le timestamp de 0h01
# date --date="2010-03-14 00:01:00" +%s
# 1268524860

ATTENTION : utiliser date OK mais sur le serveur de prod pour ne pas avoir de problème de Time Zone

# faut faire un update entre 2 time stamp si on a effacé tout ce qui est en trop avant, un > est suffisant et doit patcher uniquement le dernier enreg non? oui mais il faut justement chopper le dernier enregistrement...

# Récupération de la dernière mise à jour des joueurs concernés...
SELECT time FROM positions WHERE race=20100216 AND idusers NOT IN ( 7079, 3269, 15806, 5122, 15692, 3000,15448,4196) ORDER BY time DESC limit 1;

## 1268524809  = date --date="1970/01/01 00:00 1268524809 seconds"
# Sun Mar 14 00:00:09 GMT 2010

# Récupération des logs moteurs.
# mysql -e "select * from updates order by time desc limit 60"
#....
| 2010-03-14 13:32:14 |    12 |  1029 |      130 |  20090828 20100314 20100312 20100228 20100216 201082 20100119 20091130 20091123 20091001 60 80  | 
| 2010-03-14 13:32:04 |     1 |    25 |        1 |  20090828                                                                                       | 
.../...
| 2010-03-13 23:56:04 |     1 |    25 |        1 |  20090828                                                                                       | 
| 2010-03-13 23:55:13 |    12 |  1029 |        9 |  20090828 20100314 20100312 20100228 20100216 201082 20100119 20091130 20091123 20091001 60 80  | 

UPDATE positions SET time 20100216 AND time > (1268524860-299) AND time <= 1268524860  AND idusers NOT IN ( 7079, 3269, 15806, 5122, 15692, 3000,15448,4196) ;

# Arf... ERROR 1062 (23000): Duplicate entry '13160-20100216-1268607600' for key 
# Forcément. une clé sur le tiemstamp...
# ERROR 1062 (23000): Duplicate entry '8059-20100216-1268607605' for key 

2ème option qui a fonctionné, la première n'a pas marché car on n'utilisait pas les bons timestamps

delete from positions where race=20100216 and time < 1268520900;
delete from positions where race=20100216 and time >= 1268520900+300;
update positions set time = UNIX_TIMESTAMP(NOW())  where race=20100216;





# Mettre les races instructions à jour (mention de l'opération)
INSERT INTO races_instructions ( idraces, instructions, flag)
values (200100216, "Course redémarrée à 23h20 UTC, Cf. les détails sur le forum." , 3);

Décommenter le cron OK

Opérations postérieures au redémarrage (SQL)

# races where we don't do anything
# B2B 201082
# annuler tous les S&Go après la première vac calculée

UPDATE users SET releasetime=0 WHERE engaged IN (20100228, 201082) ;