1 votes

Existe-t-il un moyen sûr d'arrêter le serveur MySQL pendant qu'il effectue une tâche ?

Le serveur de base de données MySQL effectue une tâche depuis environ 12 heures, alors que je n'ai effectué aucune requête pendant ce temps.

Le processeur ne fait pas d'activité significative mais le disque dur est utilisé à 100% en permanence. Je suppose donc que le serveur effectue un travail de construction d'index, car cela s'est produit après que j'ai inséré environ 3,5 G de données.

Maintenant, je veux arrêter mon serveur de base de données, mais je crains que cela ne corrompe la base de données. Existe-t-il un moyen sûr d'arrêter le serveur ? Ou dois-je attendre que la tâche soit terminée ?


J'ajoute plus de détails pour clarifier et expliquer les nouveaux progrès.

Avant que le problème ne se produise, j'importais un fichier dump dont la taille était d'environ 5,5G. (J'exécutais la commande à partir de Python script.)

Mais comme cela prenait trop de temps, j'ai arrêté le processus Python avant que l'importation ne soit terminée. Après cela, le serveur mysql a effectué la tâche IO pendant plus de 12 heures et il le fait toujours.

Avec les conseils de powerload79, j'ai fait une recherche.

   SHOW FULL PROCESSLIST; 

+----+-----------------+-----------------+--------+---------+--------+------------------------+-----------------------+
| Id | User            | Host            | db     | Command | Time   | State                  | Info                  |
+----+-----------------+-----------------+--------+---------+--------+------------------------+-----------------------+
|  4 | event_scheduler | localhost       | NULL   | Daemon  | 148754 | Waiting on empty queue | NULL                  |
| 28 | root            | localhost:29209 | bitmex | Sleep   |  57594 |                        | NULL                  |
| 30 | root            | localhost:51361 | bitmex | Query   |      0 | starting               | SHOW FULL PROCESSLIST |
+----+-----------------+-----------------+--------+---------+--------+------------------------+-----------------------+
3 rows in set (0.00 sec)

Full process query result in png file

Il semblait qu'il n'y avait pas de processus pour faire la tâche IO. J'ai donc essayé d'arrêter le serveur.

Mais le serveur ne s'est pas arrêté et est passé dans un état d'attente d'arrêt. Plus d'une heure s'est écoulée dans cet état. Il y a encore beaucoup d'activité sur le disque dur dans l'état d'attente. Le serveur est hors ligne et je ne peux plus me connecter au serveur depuis le client.

Voici les journaux d'erreurs générés lorsque j'ai essayé d'arrêter le serveur :

2020-03-15T03:15:00.384460Z 0 [System] [MY-013105] [Server] C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe: Normal shutdown.

2020-03-15T03:15:02.386568Z 0 [Warning] [MY-010909] [Server] C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe: Forcing close of thread 28  user: 'root'.

2020-03-15T03:15:02.387218Z 0 [Warning] [MY-010909] [Server] C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe: Forcing close of thread 30  user: 'root'.

3voto

Anjum Kaiser Points 1016

Il n'y a pas de tâche automatisée de ce type intégrée à MySQL, vous devez donc absolument comprendre ce qu'il fait. Il est probable que quelqu'un ait configuré une sauvegarde toutes les 12 heures. Vous devriez être en mesure de voir un processus en cours d'exécution, à la fois dans la liste des processus du système et dans MySQL en utilisant SHOW FULL PROCESSLIST dans MySQL.

MySQL à l'état brut devrait être sûr, à condition que vous n'utilisiez que le moteur InnoDB, qu'aucune fonction de sécurité ne soit désactivée dans la configuration de MySQL, que la purge du cache en écriture soit activée sur vos disques et que vous soyez absolument certain que vos disques ne vous mentent pas au sujet de ces purges de cache. Cela n'est pas très différent de la simulation d'une panne de courant soudaine, contre laquelle les implémentations modernes de systèmes de fichiers et de bases de données sont raisonnablement robustes. sauf si le matériel ment (oui, cela arrive, surtout avec les anciens SSD grand public).

Même si tout ce qui est dans la pile est honnête, il y a un bémol : le démarrage de MySQL après un arrêt non nettoyé nécessite une relecture complète du journal des transactions InnoDB pour s'assurer que les données sont dans un état cohérent. Selon la taille de votre journal des transactions et la vitesse de vos disques, cela peut prendre beaucoup de temps.

0 votes

J'ai vérifié la liste complète des processus et il semble que rien ne se passe. J'ai essayé d'arrêter mysql, mais il est passé à l'état d'arrêt en attente. Plus d'une heure s'est écoulée dans cet état. Est-il prudent d'éteindre la machine ? J'ai ajouté une description supplémentaire de ce que j'ai fait dans le message original.

0 votes

J'ai attendu 5 heures de plus, mais rien n'a changé. J'ai donc tué le processus mysqld. Et j'ai redémarré mysql avec innodb-force-recovery=1. Et j'ai supprimé la table qui posait problème. Et il semble que les choses fonctionnent bien.

0 votes

Il semblerait qu'il y ait eu une corruption de disque. C'est peut-être le bon moment pour effectuer un ensemble complet d'autotests SMART sur vos disques, ainsi que tout autre contrôle d'intégrité dont vous disposez.

0voto

hbadger19042 Points 111

Je réponds à ma question pour expliquer comment j'ai géré la situation. Ce n'est pas la solution car j'ai dû supprimer une table mais j'ai pu sauvegarder les autres tables.

Je regarde la liste des processus de l'ordinateur. Il y avait deux processus mysqld. Je les ai tués tous les deux. Le serveur s'est finalement arrêté.

Lorsque j'ai essayé de redémarrer le serveur mysql, ce dernier a produit les journaux d'erreurs suivants :

2020-03-15T10:28:02.224966Z 1 [ERROR] [MY-012179] [InnoDB] Impossible de trouver un fichier associé au tablespace ID : 21

2020-03-15T10:28:02.225782Z 1 [ERROR] [MY-012964] [InnoDB] Utilisez --innodb-directories pour trouver les fichiers de tablespace. Si cela échoue, utilisez --innodb-force-recovery=1 pour ignorer ce problème et perdre définitivement toutes les modifications apportées au(x) tablespace(s) manquant(s).

J'ai résorbé avec l'option innodb-force-recovery=1. Le serveur a démarré et j'ai pu m'y connecter. Après m'être connecté au client, j'ai supprimé la table qui a provoqué tout ce désordre.

0 votes

Kevin, Bienvenue sur ServerFault. Bon travail.

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