5.3 Le processus d'extinction de MySQL

Le processus d'extinction du serveur peut se résumer comme ceci :

• Le processus est activé
• Le serveur crée un thread d'extinction, si nécessaire
• Le serveur cesse d'accepter les nouvelles connexions
• Le serveur conclut les activités en cours
• Les moteurs de stockages se ferment
• Le serveur se termine

• Le processus est activéL'extinction du serveur peut être initiée par plusieurs méthodes. Par exemple, un utilisateur avec le droit de SHUTDOWN peut exécuter la commande 'mysqladmin shutdown' . 'mysqladmin' peut être utilisée sur n'importe quelle plate-forme supportée par MySQL. Les autres méthodes d'extinction spécifiques aux systèmes d'exploitation existent aussi : le serveur s'éteind lorsqu'il reçoit un signal SIGTERM sous Unix. Un serveur installé comme service Windows s'éteind sur ordre du gestionnaire.
• Le serveur crée un thread d'extinction, si nécessaireEn fonction de l'origine de l'extinciton, le serveur peut lancer un thread qui gèrera l'extinction. Si l'extinction a été demandée par un client, un thread d'extinction est créé. Si l'extinction est le résultat d'un signal SIGTERM , le thread signal pourra gérer l'extinction lui-même, ou alors lancer un autre thread. SI le serveur essaie de créer un thread et ne peut pas le faire (par exemple, plus de mémoire), il va émettre un message qui apparaitra comme ceci dans les logs :

  Error: Can't create thread to kill server

• Le serveur cesse d'accepter les nouvelles connexionsPour éviter de voir de nouvelles opérations se lancer, le serveur commence par arrêter d'accepter les nouvelles connexions. Il fait cela en fermant les connexions au réseau qui attendent les connexions : le port TCP/IP, la socket Unix ou le Pipe Windows.
• Le serveur conclut les activités en coursPour chaque thread associé à une connexion réseau, la connexion est interrompue, et le thread est marqué comme mort. Le thread s'arrête lorsqu'il remarque qu'il a été tué. Les threads qui sont inactifs meurent rapidement. Les threads qui traitent des requêtes vérifient périodiquement leur état, et prennent plus de temps pour s'arrêter. Pour plus d'information sur la fin des threads, voyez Syntaxe de KILL , en particulier à propos des commandes REPAIR TABLE ou OPTIMIZE TABLE sur les tables MyISAM .

  Pour les threads qui ont une transaction ouverte, la transaction est annulée. Notez que si un thread modifie une table non-transactionnelle, une opération comme un UPDATE multi-ligne ou un INSERT peuvent laisser la table partiellement modifiée, car l'opération peut se terminer avant sa fin logique.

  Si le serveur est un serveur de réplication, les threads associés avec les esclaves sont traités comme n'importe quel autre client. C'est à dire, ils sont marqués comme terminés, et se termine à leur prochaine vérification d'état.

  Si le serveur est un esclave de réplication, le thread d'entre/sortie et le thread SQL sont arrêtés avant que le thread client ne soit tué. Le thread SQL est autorisé à terminer sa commande en cours (pour éviter des problèmes de réplication), puis cesse. Si le thread SQL était au milieu d'une transaction, elle sera annulée.

• Les moteurs de stockages se ferment

  A ce stade, les cache de tables ont envoyés sur le disque, et toutes les tables ouvertes sont fermées.

  Chaque moteur de stockage effectue les opérations nécessaire pour fermer les tables qu'il gère. Par exemple, MyISAM envoye les dernières écritures pour la table. InnoDB vide ses buffers sur le disque, écrit le LSN courant dans l'espace de table, et termine ses propres threads.
• Le serveur se termine