The server shutdown process takes place as follows:
The shutdown process is initiated.
This can occur initiated several ways. For example, a user with the
SHUTDOWN privilege can execute a mysqladmin shutdown command. mysqladmin can be used on any platform supported by
MySQL. Other operating system-specific shutdown initiation methods are possible as well: The server
shuts down on Unix when it receives a
SIGTERM signal. A server running
as a service on Windows shuts down when the services manager tells it to.
The server creates a shutdown thread if necessary.
Depending on how shutdown was initiated, the server might create a thread to handle the shutdown
process. If shutdown was requested by a client, a shutdown thread is created. If shutdown is the
result of receiving a
SIGTERM signal, the signal thread might handle
shutdown itself, or it might create a separate thread to do so. If the server tries to create a
shutdown thread and cannot (for example, if memory is exhausted), it issues a diagnostic message
that appears in the error log:
Error: Can't create thread to kill server
The server stops accepting new connections.
To prevent new activity from being initiated during shutdown, the server stops accepting new client connections by closing the handlers for the network interfaces to which it normally listens for connections: the TCP/IP port, the Unix socket file, the Windows named pipe, and shared memory on Windows.
The server terminates current activity.
For each thread associated with a client connection, the server breaks the connection to the client
and marks the thread as killed. Threads die when they notice that they are so marked. Threads for
idle connections die quickly. Threads that currently are processing statements check their state
periodically and take longer to die. For additional information about thread termination, see Section 184.108.40.206,
KILL Syntax", in particular for the instructions about killed
REPAIR TABLE or
OPTIMIZE TABLE operations on
For threads that have an open transaction, the transaction is rolled back. Note that if a thread is
updating a nontransactional table, an operation such as a multiple-row
may leave the table partially updated because the operation can terminate before completion.
If the server is a master replication server, it treats threads associated with currently connected slaves like other client threads. That is, each one is marked as killed and exits when it next checks its state.
If the server is a slave replication server, it stops the I/O and SQL threads, if they are active,
before marking client threads as killed. The SQL thread is permitted to finish its current statement
(to avoid causing replication problems), and then stops. If the SQL thread is in the middle of a
transaction at this point, the server waits until the current replication event group (if any) has
finished executing, or until the user issues a
KILL QUERY or
KILL CONNECTION statement. See also Section
STOP SLAVE Syntax". Since nontransactional
statements cannot be rolled back, in order to guarantee crash-safe replication, only transactional
tables should be used.
In order to guarantee crash safety on the slave, you must also run the slave with
The server shuts down or closes storage engines.
At this stage, the server flushes the table cache and closes all open tables.
Each storage engine performs any actions necessary for tables that it manages.
InnoDB flushes its buffer pool to disk (unless
innodb_fast_shutdown is 2), writes the current LSN to the tablespace,
and terminates its own internal threads.
MyISAM flushes any pending
index writes for a table.
The server exits.