Das Herunterfahren wird eingeleitet.

Das Herunterfahren des Servers kann auf mehreren Wegen veranlasst werden. So kann etwa ein Benutzer mit der Berechtigung SHUTDOWN den Befehl mysqladmin shutdown ausführen. mysqladmin kann auf jeder von MySQL unterstützen Plattform benutzt werden. Auch andere betriebssystemspezifische Methoden sind möglich, um das Herunterfahren einzuleiten: Unter Unix wird der Server heruntergefahren, wenn er ein SIGTERM-Signal empfängt. Unter Windows wird ein Server, der als Dienst ausgeführt wird, beendet, wenn der Dienste-Manager ihn dazu anweist.

Bei Bedarf erstellt der Server einen Abschaltungs-Thread.

Je nachdem, wie das Herunterfahren eingeleitet wurde, erstellt der Server unter Umständen einen Thread, um den Abschaltvorgang zu verwalten. Wurde das Herunterfahren von einem Client angefordert, dann wird ein Abschaltungs-Thread erstellt. Ist das Herunterfahren Folge eines empfangenen SIGTERM-Signals, dann erledigt der Signal-Thread die Abschaltung entweder selbst oder erstellt zu diesem Zweck einen separaten Thread. Versucht der Server vergeblich einen Abschaltungs-Thread zu erstellen (etwa weil nicht genügend Speicher zur Verfügung steht), dann gibt er eine Diagnosemeldung aus, die im Fehlerlog erscheint:

Error: Can't create thread to kill server

Der Server nimmt keine neuen Verbindungen mehr an.

Um die Initialisierung neuer Aktivitäten während des Herunterfahrens zu vermeiden, beendet der Server die Annahme neuer Clientverbindungen. Er tut dies, indem er die Netzwerkverbindungen schließt, auf denen er normalerweise auf Verbindungen horcht: den TCP/IP-Port, die Unix-Socketdatei und die Named Pipe und den gemeinsamen Speicher unter Windows.

Der Server beendet alle aktuellen Aktivitäten.

Für jeden Thread, der mit einer Clientverbindung verknüpft ist, wird die Verbindung zum Client abgebrochen, und der Thread wird als terminiert gekennzeichnet. Wenn ein Thread diese Kennzeichnung erkennt, beendet er sich. Threads leer laufender Verbindungen beenden sich sehr schnell. Threads hingegen, die zum betreffenden Zeitpunkt Anweisungen verarbeiten, überprüfen ihren Status regelmäßig und benötigen insofern länger, um sich zu beenden. Weitere Informationen zur Thread-Terminierung finden Sie in Abschnitt 13.5.5.3, „KILL“. Beachten Sie dort insbesondere die Erläuterungen zu terminierten REPAIR TABLE- und OPTIMIZE TABLE-Operationen an MyISAM-Tabellen.

Wenn bei Threads eine Transaktion offen ist, wird diese via Rollback rückgängig gemacht. Beachten Sie, dass, wenn ein Thread eine nicht transaktionssichere Tabelle aktualisiert, Anweisungen für mehrere Datensätze wie UPDATE oder INSERT eine teilaktualisierte Tabelle entstehen lassen können, weil der Vorgang vor seinem Abschluss terminiert werden kann.

Wenn der Server ein Master-Replikationsserver ist, werden Threads, die derzeit angeschlossenen Slaves zugeordnet sind, wie andere Client-Threads behandelt. Das bedeutet, dass jeder dieser Threads als terminiert gekennzeichnet wird und sich beendet, sobald er zum nächsten Mal seinen Status überprüft.

Ist der Server ein Slave-Replikationsserver, dann werden die E/A- und SQL-Threads – sofern aktiv – beendet, bevor Client-Threads als terminiert gekennzeichnet werden. Der SQL-Thread darf seine aktuelle Anweisung abschließen, um Replikationsprobleme zu vermeiden, und wird dann beendet. Befand sich der SQL-Thread zu diesem Zeitpunkt mitten in einer Transaktion, dann wird diese Transaktion rückgängig gemacht.

Speicher-Engines werden heruntergefahren oder geschlossen.

An dieser Stelle wird der Tabellen-Cache auf die Festplatte geschrieben, und alle offenen Tabellen werden geschlossen.

Alle Speicher-Engines führen ggf. Vorgänge aus, die für die jeweils verwalteten Tabellen erforderlich sind. So synchronisiert MyISAM beispielsweise alle anhängigen Indexschreiboperationen für eine Tabelle. InnoDB schreibt seinen Pufferpool auf die Festplatte (sofern innodb_fast_shutdown nicht 2 ist), speichert die aktuelle LSN in den Tablespace und beendet seine eigenen internen Threads.

Der Server wird beendet.