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
Voici une version plus détaillée de ce synopsis :
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écessaire
En 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 connexions
Pour é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 cours
Pour 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
Section 13.5.4.3, « 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
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.