Ralentissements de yN - Page 2

Je relance Infomaniak...

[edit] Ils ont répondu, blabla serveur en surcharge (encore ?!), ils prévoient une migration en début de semaine prochaine. J'essaie d'avoir un peu plus de détail parce que ça commence à faire beaucoup là.

[edit] Changement de serveur prévu mercredi prochain dans la journée, a priori sans interruption.

#croise-les-doigts#

Visiblement Orion_ est en train de faire tourner son script pour éditer tous ses posts, et yN rame à fond en ce moment...

Zerosquare (./33) :
Visiblement Orion_ est en train de faire tourner son script pour éditer tous ses posts, et yN rame à fond en ce moment...

et pourquoi ça serait le sien et pas le tien ?

Parce que moi, j'indexe à la volée et à la main ^^

Zerosquare (./33) :
Visiblement Orion_ est en train de faire tourner son script pour éditer tous ses posts, et yN rame à fond en ce moment...

Sérieusement ?

Ouais.

Et j'ai des dizaines de topics qui sont réapparus dans "non lus" parce qu'Orion_ était le dernier à avoir posté dedans...

pfffffff...

Déjà c'est pénible, mais en plus s'il ne met pas de sleep c'est franchement pas correct.

Pen^2 (./36) :
Sérieusement ?

Oui, c'est pas la première fois qu'il fait ça.

Oui mais je pensais que c'était un peu plus subtil, avec un sleep par exemple.

ca c'est un peu for(;;) !

Pour rappel, c'est aujourd'hui qu'Infomaniak migre la base de données sur un nouveau serveur. Même s'ils ont avancé une migration sans interruption, je n'y crois que très moyennement donc il n'est pas impossible que le site disparaisse pendant une petite heure

Cool, merci, il ne reste plus qu'à espérer que la migr

Bon, bah on dirait bien qu'il y a eu un trou temporel, merci Infomaniak ! Je vais voir si je peux restaurer les données concernées.

pas de risque de perte de posts ? (ou de réapparition)

Aucune idée, il ne m'ont donné aucun détail technique sur la migration.

Suite de ./45 : j'ai restauré à la main tous les messages qui ont été perdus (je suppose qu'Infomaniak a fait un snapshot puis démarré la migration, du coup ils ont paumé tout ce qu'il s'est passé entre temps). Ça provoque potentiellement des choses curieuses comme les messages ./46 et ./47 de ce sujet qui apparaissent après le ./45 alors qu'ils ont été postés avant, mais au moins on a pas perdu de contenu.

J'espère qu'au moins avec tout ça le problème des ralentissements sera résolu !

Merci pour ton support !

Du coup, mon ./44 prend tout son sens

En tout cas, merci beaucoup, c'est un peu des tanches

A vrai dire je vois pas, sans qu'il y ai perte de donnée on peux faire une migration "invisible" tu es oblige de bloquer le serveur d'origine en ecriture, faire un dump, ecrire le dump sur le nouveau serveur et le mettre a la place de l'autre.

Il y a forcement un temps mort ou la BDD n'est pas accessible au moins en écriture

(Attention, le comité des tanches va s'énerver sur twitter )

Godzil (./51) :
A vrai dire je vois pas, sans qu'il y ai perte de donnée on peux faire une migration "invisible" tu es oblige de bloquer le serveur d'origine en ecriture, faire un dump, ecrire le dump sur le nouveau serveur et le mettre a la place de l'autre.

Il y a forcement un temps mort ou la BDD n'est pas accessible au moins en écriture

il reste la solution de "réplication à chaud" comme on en a dans le cas des load balancers : ta base est d'abord dupliquée depuis une image à un instant T et ensuite le nouveau serveur se met à jour en même temps que l'ancien et les requêtes sont mirorées sur les deux. Et le changement se fait juste par une configuration du load balancer qui dit "ne plus utiliser le serveur ancien" qu'on peut ensuite mettre horsligne

mais c'est chaudcoton ca...

le problème c'est de pas avoir bloqué l'accès en écriture après le snapshot.

mysqld stop / migration / mysqld start aurait été plus efficace, yN en rade quand même, mais pas de faille spatiotemporelle.

Vince: je ne connaissait pas cette méthode, mais il faut qu'elle soit en place des le début pour pouvoir être utilisé j'imagine, mais je vois l'idée.

- A un certain moment on fait, via le loadbalancer une copie du serveur #1 vers le serveur #2,
- le loadbalancer reste configuré pour ne fournir que #1 uniquement mais garde un historique des requêtes en écritures faites sur #1 depuis le début de la copie
- des que #2 est prêt, le loadbalancer fait un replay des requêtes d’écritures en attente
- Des que la liste est faite, et que #1 et #2 sont parfaitement synchrone, on dit au loadbalancer de basculer sur #2 uniquement et la on peux couper #1 et le mettre a la benne

C'est l'idee?
(oui je dit probablement la même chose que toi mais besoin de reformuler avec mes mots histoire d’être sur d'avoir compris l'idée)

En tout cas ce n'est apriori pas la solution qu'ils ont choisis XD

oui, c'est l'idée

(Boarf, c'est bon la tanche !)

Ils auraient pu monter un backup, le configurer en slave du serveur actuel avec une réplication, puis le jour J intervertir le master et le slave (via DNS) pour enfin virer l'ancien serveur. Je pense que MySQL possède tout ce qu'il faut pour faire ça sans trop de soucis, mais bon visiblement ils ont préféré une approche plus directe, peu importe au moins c'est fait ^^

Oui mysql permet d'écrire un log des requêtes notamment.

Ben la moindre des choses aurait été de dire qu'il fallait interrompre le service Web à partir d'une certaine heure pour éviter les problèmes. Ca a l'avantage de ne pas nécessiter un niveau de technicité très élevé ^^