The Server Shutdown Process next-transaction characteristics that were set preceding the start of the transaction have been reset, and that the session defaults apply. To track changes to those session defaults, track the session values of the transaction_isolation  and  transaction_read_only  system variables. The server shutdown process takes place as follows: 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. 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: 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. 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 13.7.8.4, “KILL Statement” , in particular for the instructions about killed  REPAIR TABLE  or  OPTIMIZE TABLE operations on  MyISAM  tables. For threads that have an open transaction, the transaction is rolled back. If a thread is updating a nontransactional table, an operation such as a multiple-row  UPDATE  or  INSERT  may leave the table partially updated because the operation can terminate before completion. If the server is a replication source server, it treats threads associated with currently connected replicas 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 replica server, it stops the replication 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 13.4.2.10, “STOP SLAVE | REPLICA Statement” . Since nontransactional statements cannot be rolled back, in order to guarantee crash-safe replication, only transactional tables should be used. 1014 1. The shutdown process is initiated. 2. The server creates a shutdown thread if necessary. 3. The server stops accepting new connections. 4. The server terminates current activity. Error: Can’t create thread to kill server 5.1.19 The Server Shutdown Process