The server shutdown process takes place as follows:
The shutdown process is initiated.
Server shutdown can be initiated several ways. For example, a
user with the
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. (On Windows, a user with Administrator rights can also
shut down the server using
service_name is the name of the
MySQL service. By default, this is
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. It does this by closing the network connections 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 that is associated with a client connection,
the connection to the client is broken and the thread is
marked 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 188.8.131.52, “KILL Syntax”, in particular for the instructions
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
INSERT may leave the table
partially updated, because the operation can terminate before
If the server is a master replication server, threads associated with currently connected slaves are treated 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, the I/O and SQL threads, if active, are stopped before client threads are marked as killed. The SQL thread is permitted to finish its current statement (to avoid causing replication problems), and then stops. If the SQL thread was in the middle of a transaction at this point, the transaction is rolled back.
Storage engines are shut down or closed.
At this stage, the table cache is flushed and all open tables are closed.
Each storage engine performs any actions necessary for tables
that it manages. For example,
flushes any pending index writes for a table.
InnoDB flushes its buffer pool to disk,
writes the current LSN to the tablespace, and terminates its
own internal threads.
The server exits.