Quelles sont les causes courantes et les solutions aux pannes de base de données MySQL

Vérifiez l'heure de démarrage de la base de données MySQL

systemd et mysqld_safe dans le système Linux redémarreront automatiquement le service MySQL après le crash du processus mysqld. Il convient de noter que l'utilisation de kill -9 pour tuer le processus mysqld tuera automatiquement. redémarrez le système, et seule l'utilisation de la commande kill ne redémarrera pas, car lorsque la commande kill est exécutée, le système enverra un signal SIGTERM à mysqld, la base de données mysql sera arrêtée normalement et un enregistrement similaire à celui-ci sera créé. apparaître dans le journal :

2020-10-26T09 : 06:48.435181Z 0 [Système] [MY-010910] [Serveur] /usr/sbin/mysqld : Arrêt terminé (mysqld 8.0.19) MySQL Community Server - GPL .

La base de données MySQL sera redémarrée après un crash, nous pouvons donc parfois ne pas savoir que la base de données MySQL est tombée en panne, mais nous pouvons trouver des indices sur l'heure de démarrage de la base de données MySQL. Voici quatre façons de vérifier l'heure de démarrage de la base de données MySQL.

La vérification de l'état du service MySQL

scutech@scutech:~$ service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days ago
  Process: 774 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/SUCCESS)
  Process: 708 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 791 (mysqld)
    Tasks: 27 (limit: 2328)
   CGroup: /system.slice/mysql.service
           └─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

montre que la base de données MySQL fonctionne depuis plus de 4 jours.

Vérifiez l'état de disponibilité dans MySQL

mysql> show global status like 'uptime';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Uptime        | 428334 |
+---------------+--------+
1 row in set (0.32 sec)

Cette valeur est en secondes La conversion suivante en jours est supérieure à 4 jours.

mysql> select 428334/60/60/24;
+-----------------+
| 428334/60/60/24 |
+-----------------+
|  4.957569444444 |
+-----------------+
1 row in set (0.01 sec)

Une autre façon d'interroger l'état de disponibilité consiste à utiliser la version mysqladmin ou à utiliser "s" dans le client mysql pour interroger.

Utilisez ps pour vérifier l'heure de démarrage du processus

Utilisez la commande ps pour interroger et constater que mysqld a été démarré depuis 4 jours, 23 heures, 3 minutes et 54 secondes

scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld
  791 mysql    /usr/sbin/mysqld --daemoniz  4-23:03:54

Vérifiez le journal MySQL

Recherchez le mot-clé "prêt pour les connexions" pour trouver les informations de démarrage.

2020-10-21T08:24:18.986765Z 0 [Note] /usr/sbin/mysqld : prêt pour les connexions.
Version : '5.7.28-log' socket : '/var/run/mysqld/mysqld. port sock : 3306 MySQL Community Server (GPL)

Raisons courantes du crash de la base de données MySQL

Il existe deux raisons les plus courantes du crash de la base de données MySQL, l'une est un bug MySQL, l'autre est l'échec de MySQL à demander des ressources système ou fuites de mémoire.

Bogue MySQL

L'une des raisons les plus courantes du crash de la base de données MySQL est bien sûr le bogue MySQL. 95 % des bogues sont liés à un SQL spécifique. Il y a généralement un problème avec le dernier SQL exécuté avant le crash de MySQL. Par conséquent, lors de la localisation du bug, vous devez ouvrir le journal des requêtes générales et rechercher des indices basés sur le dernier SQL.
Après avoir déterminé la cause du crash, vous devez consulter la bibliothèque de bogues MySQL (https://bugs.mysql.com), généralement en utilisant la recherche avancée, pour voir s'il existe des problèmes similaires. Si vous trouvez un bug qui peut vous concerner, confirmez qu’il a été corrigé. S'il a été corrigé, mettez à niveau MySQL vers une version dans laquelle le bogue a été corrigé.

Il y a une section Bugs corrigés dans les notes de version de chaque version, où vous pouvez vérifier les bugs corrigés.

MySQL ne parvient pas à demander les ressources système ou les fuites de mémoire

Une mémoire insuffisante ou MySQL ne parvient pas à demander les ressources système entraînera le crash de MySQL, par exemple, l'espace disque est plein, les fichiers sur le disque sont corrompus, etc. À l'heure actuelle, il existe plusieurs méthodes pour localiser la cause première du crash :

• Lisez attentivement le journal des erreurs MySQL. Certaines informations de débogage du programme contenues dans ce journal peuvent sembler déroutantes, mais si vous vous calmez et regardez attentivement, plusieurs fois, il trouvera des indices ;

• Ouvrez le journal des requêtes générales, recherchez la table ou l'index accédé par le dernier SQL, vérifiez la table ou l'index et reconstruisez s'il y a un problème, ce qui résout généralement le problème.

• Utilisez strace, pstack, pmap, gdb pour analyser le code de mysqld, vous devrez peut-être ouvrir le core dump ;

• Utilisez l'option CMake -DWITH_DEBUG=1 pour recompiler mysqld, puis exécutez le mysqld recompilé et affichez le fichier de trace, journal des erreurs pour le dépannage. Calcul de l'utilisation de la mémoire MySQL _buffer _size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size

Formule de calcul

Valeur de référence d'utilisation maximale de la mémoire dans MySQL 8 Calcul formule :

SELECT ( @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size 
+ @@max_connections * (@@binlog_cache_size + @@thread_stack + @@read_buffer_size 
+ @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size ) 
) / 1024 /1024 AS MAX_MEM_MB;

innodb_buffer_pool_size

key_buffer_size

max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)

max_connections*2MB

• Comme solution temporaire, vous pouvez utiliser la commande suivante pour libérer le cache :

echo 1 > /proc/sys/vm/drop_caches

• 0 : 0 est la valeur par défaut du système. Par défaut, cela signifie que la mémoire n'est pas libérée et est automatiquement gérée par le système d'exploitation. 1 : Libérer le cache des pages. 2 : Libérer les entrées et les inodes. caches. À long terme, vous devez toujours modifier les paramètres correspondants.
  Fuites de mémoire du client MySQL
• Les fuites de mémoire du client MySQL ont généralement les invites suivantes

  mysql : Mémoire insuffisante à la ligne 42, 'malloc.c'
  mysql : 8 136 octets (8 ko) nécessaires, mémoire utilisée : 12481367 octets (12189 ko)
  ERREUR 2008 : le client MySQL n'a plus de mémoire

  Ceci est Cela est généralement dû au fait que l'ensemble de résultats renvoyés reçu par le client est trop volumineux. Il existe deux solutions :

  Vérifiez le SQL en cours d'exécution pour voir si vous avez vraiment besoin d'un ensemble de résultats renvoyés aussi volumineux ?
  Autorisez mysql avec l'option --quick, ce qui réduira l'ensemble de retours reçu par le client à la fois, mais augmentera la charge de mysqld.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!