4 votes

La sauvegarde TKLBAM qui bloque entraîne des problèmes de MySQL

J'ai un problème étrange que je n'ai jamais rencontré auparavant. Je fais tourner un serveur Turnkey Linux LAMP (Debian) et il semble que mon serveur MySQL devienne inaccessible au moins une fois par jour. Je ne suis pas sûr du tout de ce qui cause cela. Mes derniers logs avant de le redémarrer sont les suivants :

160108 0:54:09 [Note] Plugin 'FEDERATED' est désactivé.
160108 0:54:09 InnoDB: Le tas de mémoire InnoDB est désactivé
160108 0:54:09 InnoDB: Mutexes et rw_locks utilisent des builtins atomiques GCC
160108 0:54:09 InnoDB: Les tables compressées utilisent zlib 1.2.8.
160108 0:54:09 InnoDB: Utilisation de Linux native AIO
160108 0:54:09 InnoDB: Initialisation du pool de buffers, taille = 128.0M
160108 0:54:09 InnoDB: Initialisation complétée du pool de buffers
160108 0:54:09 InnoDB: le format de fichier supporté le plus élevé est Barracuda.
160108 0:54:09 InnoDB: En attente du démarrage des threads de fond
160108 0:54:10 InnoDB: 5.5.46 démarré ; numéro de séquence de journal 111777334
160108 0:54:11 [Note] /usr/sbin/mysqld: prêt pour les connexions.
Version: '5.5.46-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  (Debian)

Je n'ai pas changé les paramètres par défaut que je me souvienne, donc il devrait écouter sur 3306. J'ai quelques sites Wordpress qui tournent sur le serveur, donc avoir la base de données qui tombe en panne comme ça est une mauvaise nouvelle. Elle se relance tout de suite quand je la redémarre sans problème et indique qu'elle écoute sur 3306 :

160108 10:20:45 [Note] Socket serveur créé sur IP : '127.0.0.1'.
160108 10:20:45 [Note] Planificateur d'événements : 0 événements chargés
160108 10:20:45 [Note] /usr/sbin/mysqld: prêt pour les connexions.
Version: '5.5.46-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)

Des idées ? Merci !

MISE À JOUR : Voici mon fichier de log complet : http://pastebin.com/2G2CAVsw

LE PROBLÈME : Il semblerait que tklbam-restore soit à l'origine du problème. J'ai lancé manuellement une sauvegarde et remarqué qu'une fois arrivé à la phase de la base de données, mes serveurs Wordpress ne pouvaient plus accéder à MySQL. De plus, le processus de sauvegarde semble être bloqué sur l'une de mes tables de base de données. Voici les dernières lignes :

table: trendsandteens/wp_wfNet404s
table: trendsandteens/wp_wfReverseCache
table: trendsandteens/wp_wfScanners
table: trendsandteens/wp_wfStatus
table: trendsandteens/wp_wfThrottleLog
table: trendsandteens/wp_wfVulnScanners

Il ne sauvegarde que les tables de Wordfence. Donc je ne suis pas sûr de ce que le problème pourrait être... Des idées ? Voici la trace après avoir interrompu le processus : http://pastebin.com/QV63cBPG

1voto

Jonathan Mayhak Points 4183

Essayez de démarrer MySQL en utilisant strace et enregistrez la sortie dans un fichier. Ensuite, examinez la sortie juste avant qu'elle ne se termine pour voir s'il y a quelque chose qui pointerait vers la cause du problème.

Sachez cependant que la sortie peut devenir assez volumineuse, donc assurez-vous de ne pas manquer d'espace disque ou d'avoir un impact négatif sur le système (comme s'il nécessitait beaucoup d'E/S pour écrire toutes les données sur le disque).

Si vous constatez que des chaînes ont été tronquées et qu'il serait utile de les avoir pour enquêter plus avant, utilisez l'argument -s avec strace.

Si c'est plus simple, vous pouvez attacher strace à un processus existant en utilisant -p idduprocessus.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X