MySQL tombe en panne à cause d'un bogue

Pour que linode vous envoie un email au sujet du dépassement du seuil d'IO pendant plus de deux heures comme ça, je pense que quelque chose provoque une forte IO du disque. Êtes-vous à court de mémoire ou quelque chose de ce genre dans le processus ? Souvent, sur les systèmes VPS comme Linode, le fait de voir un IO élevé sur le disque est dû à un manque de mémoire et à un swapping en cours. OOMkiller peut être invoqué, ce qui tue mysql. Est-ce que dmesg montre une mention de oomkiller ?

Quand vous dites que le serveur se bloque, que voulez-vous dire exactement ?

Voulez-vous dire que le système redémarre ou se bloque (il ne répond plus et doit être réinitialisé ou mis sous tension) ?

Ou voulez-vous dire seulement que MySQL se bloque - si c'est le cas, voulez-vous dire qu'aucun processus MySQL ne fonctionne ou que tous les processus MySQL ne répondent pas aux requêtes ?

Est-ce que quelque chose apparaît sur la console système lorsque cela se produit ?

Je pense que les avertissements de MySQL n'ont rien à voir avec le problème - d'après ce que j'ai lu dans le rapport de bogue que vous citez, il ne s'agit pas d'un problème qui fait planter MySQL, et encore moins le système.

L'avertissement n'est que cela - un avertissement. Je ne pense pas que ce soit votre problème. Essayez d'augmenter la journalisation de mysql. Est-il possible que lorsque vous atteignez les limites du seuil d'E/S, Linode commence à rejeter vos demandes d'E/S, et cela provoque le crash ou la fin de mysql ?