Safely shut down MySQL

step

1. In some special environments, the slave node may try to start from the wrong position. In order to reduce this risk, stop the io thread first, so as not to receive new event information

mysql> stop slave io_thread;
mysql> show slave status\G
mysql> stop slave sql_thread; //After the sql thread has applied all the events, also stop the sql thread

In this way, the io thread and the sql thread can be in a consistent position, so that the relay log only contains the events that have been executed, and the location information in the relay_log_info_repository is also the latest.

Start the slave of multi-threaded replication, make sure that the gaps have been filled before closing the replication:
mysql> stop slave;
mysql> start slave until sql_after_mts_gaps; #After applying the gap in the relay log
mysql> show slave status\G #Make sure to Sql_thread
mysql> stop slave has been stopped before ;

2. Commit, roll back or kill long-running transactions

Many things can happen within 1 minute. When shutting down, InnoDB must roll back uncommitted transactions. The cost of transaction rollback is very expensive and may take a long time. Any transaction rollback may mean data loss, so ideally we hope that MySQL does not open any transactions when it is closed.

If the database is closed for reading and writing, write operations should be routed to other nodes in advance. If you must close the database that is still receiving transactions, the following query will output session information that has a running time greater than 60 seconds. Based on this information, decide the next step:

mysql> SELECT trx_id, trx_started, (NOW() - trx_started) trx_duration_seconds, id processlist_id, user, IF(LEFT(HOST, (LOCATE(':', host) - 1)) = '', host, LEFT(HOST, (LOCATE(':', host) - 1))) host, command, time, REPLACE(SUBSTRING(info,1,25),'\n','') info_25 FROM information_schema.innodb_trx JOIN information_schema.processlist ON innodb_trx.trx_mysql_thread_id = processlist.id WHERE (NOW() - trx_started) > 60 ORDER BY trx_started;

+--------+---------------------+----------------------+----------------+------+-----------+---------+------+---------------------------+
| trx_id | trx_started         | trx_duration_seconds | processlist_id | user | host      | command | time | info_25                   |
+--------+---------------------+----------------------+----------------+------+-----------+---------+------+---------------------------+
| 511239 | 2020-04-22 16:52:23 |                 2754 |           3515 | dba  | localhost | Sleep   | 1101 | NULL                      |
| 511240 | 2020-04-22 16:53:44 |                   74 |           3553 | root | localhost | Query   |   38 | update t1 set name="test" |
+--------+---------------------+----------------------+----------------+------+-----------+---------+------+---------------------------+
2 rows in set (0.00 sec)

3. Clear the processlist

mysql wants to disconnect and close. We can manually use pt-kill to view and kill connections in active and sleeping states. There should be no new write connections coming in at this time. We just deal with read connections.

pt-kill --host="localhost" --victims="all" --interval=10 --ignore-user="pmm|orchestrator" --busy-time=1 --idle-time=1 --print [--kill]

-Ignore-user can selectively exclude connections established by certain users.

4. Configure innodb to complete the maximum refresh (flush)

SET GLOBAL innodb_fast_shutdown=0;
SET GLOBAL innodb_max_dirty_pages_pct=0;
SET GLOBAL innodb_change_buffering=‘none’;

Disabling innodb_fast_shutdown may cause the shutdown process to take several minutes or even hours, because you need to wait for the purge of the undo log and the merge of the changebuffer. To speed up the shutdown, set innodb_max_dirty_pages_pct=0 and monitor the results of the following query. The expected value is 0, but it is not always guaranteed if there is still activity in mysql. Then, if the detected result does not continue to become smaller, you can proceed to the next step:

5. Dump the contents of the buffer pool

SET GLOBAL innodb_buffer_pool_dump_pct=75;
SET GLOBAL innodb_buffer_pool_dump_now=ON;

At startup, if you want to load the dumped content, check the configuration of the parameter innodb_buffer_pool_load_at_startup.

6, refresh the log

FLUSH LOGS;

7, close mysql

Mysql shutdown process

1. Closing process:

1. Initiate shutdown and send out SIGTERM signal

2. If necessary, create a new shutdown thread

If it is a client-initiated shutdown, a dedicated shutdown thread will be created

If it is closed by receiving the SIGTERM signal directly, the thread specifically responsible for signal processing will be responsible for the shutdown, or a new independent thread will be responsible for this matter.

When an independent shutdown thread cannot be created (such as insufficient memory), MySQL Server will issue a warning message similar to the following:

Error: Can’t create thread to kill server

3. MySQL Server no longer responds to new connection requests

Close TCP/IP network monitoring , close Unix Socket and other channels

4. Gradually close the current connection and transaction

Idle connections will be terminated immediately;

There are currently transactions and SQL active connections, which will be marked as killed, and their status will be checked regularly so that they can be closed during the next check;

If there is currently an active transaction, the transaction will be rolled back. If the non-transactional table is also modified in the transaction, the modified data cannot be rolled back, and only partial changes may be completed;

If it is the Master in the Master/Slave replication scenario, the processing of the replication thread is the same as that of the ordinary thread;

If it is the slave in the Master/Slave replication scenario, the IO and SQL threads will be closed in turn . If these two threads are currently active, the killed flag will also be added and then closed;

On the Slave server, the SQL thread is allowed to directly stop the current SQL operation (in order to avoid replication problems), and then close the thread;

In MySQl 5.0.80 and earlier versions, if the SQL thread executes a transaction in the middle, the transaction will roll back; starting from 5.0.81, it will wait for all operations to end, unless the user initiates a KILL operation.

When Slave's SQL thread is forced to KILL when performing operations on non-transactional tables, it may cause inconsistent Master and Slave data;

5. The MySQL Server process closes all threads and closes all storage engines;

Refresh all table caches and close all open tables;

Each storage engine is responsible for related shutdown operations. For example, MyISAM will flush all operations waiting to be written; InnoDB will flush the buffer pool to disk (starting from MySQL 5.0.5, if innodb_fast_shutdown is not set to 2), set the current The LSN is recorded in the table space, and then all internal threads are closed.

6. The MySQL Server process exits

2. About the KILL instruction

Starting from 5.0, KILL supports specifying two options: CONNECTION | QUERY :

@KILL CONNECTION is the same as the original one, stop rolling back the transaction, close the thread connection, and release related resources;

@KILL QUERY only stops the operation currently submitted by the thread for execution, and the others remain unchanged;

After submitting the KILL operation, a special kill flag bit will be set on the thread . It usually takes a while to actually shut down the thread, because the kill flag is only checked under certain circumstances:

1. When executing a SELECT query, in the ORDER BY or GROUP BY loop, the kill flag bit will be checked every time some row record block is read. If it is found to exist, the statement will be terminated;

2. When ALTER TABLE is executed, the kill flag will be checked after reading some row record blocks from the original table. If it is found to exist, the statement will be terminated and the temporary table will be deleted;

3. When performing UPDATE and DELETE, every time some row record block is read and updated or deleted, the kill flag will be checked. If it is found to exist, the statement will be terminated and the transaction will be rolled back. If it is an operation on a non-transactional table, it will be The changed data will not be rolled back;

4. The GET_LOCK() function returns NULL;

5. The INSERT DELAY thread will quickly add new records in memory and then terminate;

6. If the current thread holds a table-level lock, it will be released and terminated;

7. If the thread's write operation call is waiting to release the disk space, it will directly throw a "disk space full" error, and then terminate;

8. When the MyISAM table is KILL during the execution of REPAIR TABLE or OPTIMIZE TABLE, the table will be damaged and unusable, and the repair will be completed again.

Three, some suggestions for safely shutting down MySQL

To safely shut down the mysqld service process, follow the steps below:

0. Use an account with the highest authority such as SUPER and ALL to connect to MySQL, preferably unix socket connection;

1. In version 5.0 and above, set innodb_fast_shutdown = 1 to allow fast shutdown of InnoDB (without full purge, insert buffer merge), if it is for upgrading or downgrading the MySQL version, do not set it;

2. Set innodb_max_dirty_pages_pct = 0 to let InnoDB flush all dirty pages to disk;

3. Set max_connections and max_user_connections to 1, which means that in the end, no new connection is allowed to be created except for your current connection;

4. Close all inactive threads, that is, thread IDs whose state is Sleep and whose Time is greater than 1;

5. Execute SHOW PROCESSLIST to confirm whether there are still active threads, especially threads that will generate table locks , such as SELECTs with large data sets, or large-scale UPDATEs, or executing DDL. You must be particularly cautious;

6. Execute SHOW ENGINE INNODB STATUS to confirm that the value of History list length is low (generally lower than 500), that is, there are few transactions without PURGE, and confirm that the Log sequence number, Log flushed up to, and Last checkpoint at three states The value is the same, that is, all LSNs have been checked;

7. Then execute the FLUSH LOCKAL TABLES operation, refresh all table caches, and close the opened tables (the function of LOCAL is that this operation does not record BINLOG);

8. If it is a SLAVE server, it is best to close IO_THREAD first, wait for all RELAY LOGs to be applied, and then close SQL_THREAD to avoid SQL_THREAD being terminated during the execution of large transactions, and wait patiently for all applications to be completed. If you must close it forcibly, It is also best to wait for the end of the large transaction before closing SQL_THREAD;

9. Finally, execute mysqladmin shutdown.

10. In an emergency, you can set innodb_fast_shutdown = 1, and then directly execute mysqladmin shutdown, or even call kill or kill -9 directly at the operating system layer to kill the mysqld process (some transactions may be lost when innodb_flush_log_at_trx_commit = 0), However, when the mysqld process starts again, it will perform CRASH RECOVERY work, which needs to be weighed.

Innodb_fast_shutdown tells Innodb what to do when it shuts down. There are three values ​​to choose from:

  1. 0 means that when InnoDB is closed, you need to purge all, merge insert buffer, and flush dirty pages. This is the slowest way to shut down, but it is also the fastest at restart. The meaning of purge all, merge insert buffer, and flush dirty pages will be introduced later.
  2. 1 means that when InnoDB is closed, it does not need to purge all, merge insert buffer, only flush dirty page.
  3. 2 means that when InnoDB is closed, it does not need to purge all, merge insert buffer, nor flush dirty pages, but only flush the logs in the log buffer to log files. So it is the most time-consuming when it comes to restoring.

Fourth, the recovery process

When mysql restart, its recovery process (also called crash recovery)

  1. If innodb_fast_shutdown=2 or mysql crash occurred when innodb was shut down last time, then it will use redo log to redo those committed transactions.
  2. The next operations are as follows:
    a> Rollback uncompleted transitions cancel those uncommitted transactions
    b> Purge all clear useless undo pages
    c> Merge insert buffer merge insert buffer

Reprinted; https://www.cnblogs.com/DataArt/p/10218602.html

Guess you like

Origin blog.csdn.net/ximenjianxue/article/details/114893542