关于mysql:MySQL-启停过程了解一二

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。
GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。

前言

你晓得MySQL启停都做了些什么吗？启动的时候初始化配置文件，读取redo配合binlog进行事务recover；进行的时候如同没有啥操作可做；印象中除了这些，就再没有了，至多在明天之前，我是这么认为的，我是真的浮浅。
明天就来聊一聊MySQL对于启停的惯例操作。

进行过程

先说一下比较简单的进行过程

1) 能够由具备shutdown权限的用户在客户端执行shutdown命令敞开，或者是由mysqladmin shutdown敞开；

2) 如果是由客户端发动的shutdown，则须要创立独自的线程进行敞开后续操作；如果server是接管到SIGTERM信号(linix操作系统的kill命令产生的信号)，则由接管到信号的线程执行敞开操作。须要留神的是，如果此时服务器内存应用十分高，可能会敞开失败，并将失败信息记录到error日志中。

:::block-1

阐明：

SIGTERM 这个是shell命令kill默认的信号，过程收到此信号后，能够持续做一些解决而后再退出，具体的命令为kill pid 或者kill -15 pid，即这两个命令收回后，过程会平安的退出。

SIGKILL 这个是shell命令kill -9 pid发送的信号，过程接管到此信号后，会立刻进行过程，无奈按失常的退出流程执行。

因而，在linux操作系统中，如果应用kill命令进行MySQL服务，倡议应用kill (-15) pid，而不是kill -9 pid，尽管kill -9可能疾速进行，然而可能会对数据、文件造成毁坏，导致数据库无奈启动。
:::

3) 敞开新的的连贯申请，回绝所有尝试通过TCP/IP、socket、pip、shared memory的建设的连贯。

4) 终止以后沉闷过程。其操作形式是标记所有线程的状态为killed，和咱们通过mysql client收回kill processlist_id一样，如果thread为sleep状态，线程很快就敞开。如果是正在运行语句的线程，并且是在事务中(比方innodb的dml)，则会进行回滚；如果是非事务中的语句(比方myisam表的dml)则会终止，导致批量插入可能局部胜利，SQL执行后果与预期不符。有一个非凡状况，如果实例是slave节点，会期待sql_thread线程执行完以后的组事务、SQL命令，以缩小复制问题。

5) 敞开server层、敞开存储引擎层。在这一步，会刷新表构造到磁盘，敞开所有关上的表，刷新LSN到表空间文件(ibd文件)。另外很重要的一点，对于innodb存储引擎，会将innodb_buff_pool中的局部内容刷新到磁盘(如果innodb_fast_down设置为2，则不会刷新innodb_buff_pool到磁盘)。

6) MySQL实例敞开胜利，返回操作后果的状态码(0/1/2)。

如果是由shell发动了kill -9，第3、4、5步都不会有，间接跳过

启动过程

本章节原本是打算详细描述下MySQL的启动过程，然而能力无限，临时只察看到以下大略的启动步骤

整个启动过程，其余步骤比拟容易了解，唯独复原innodb_buffer_pool这一步骤是以前未曾察看到的，明天就来重点聊一下它。

性能阐明

为了防止重新启动MySQL服务后长时间的预热，特地是对于设置了比拟大的innodb_buffer_pool_size的实例，能够在服务器敞开时保留buffer_pool内容，并在服务器启动时将buffer_pool复原到敞开前的状态，防止数据库刚开始运行的一段时间内业务拜访所有申请数据页都须要从新从磁盘上读取，减小数据库重启对系统带来的性能影响。

此性能在5.6版本引入，默认敞开；在5.7及之后的版本，就默认关上此性能。

参数阐明

innodb_buffer_pool_dump_at_shutdown -- 管制在实例敞开时保留innodb_buffer_pool内容innodb_buffer_pool_dump_pct         -- 管制保留innodb_buffer_pool的残缺度，默认25%，此参数是在5.7中减少。innodb_buffer_pool_load_at_startup  -- 管制在实例启动时加载上次敞开时保留的innodb_buffer_pool内容

应用介绍

一般来说，实例运行过程中会加载大量数据进入buffer_pool中，然而在保留innodb_buffer_pool内容时，并不会残缺的保留所有数据，而是仅仅保留innodb_buffer_pool_dump_pct百分比的数据，按最近拜访工夫程序保留，

数据能够在information_schema.INNODB_BUFFER_PAGE_LRU中查问到，保留的内容也仅仅是保留了SPACE_ID+PAGE_NUMBER，而后通过这两个属性组成的惟一值，到物理磁盘上获取残缺数据，

保留的文件是在数据目录的ib_buffer_pool文件中，文件名是由innodb_buffer_pool_filename管制，能够看到相比innodb_buffer_pool_size的设置值，该文件十分小

[#3#root@greatdb81 /greatdb/dbdata/datanode4406/data 15:38:54]3 ll ib_buffer_pool -rw-r-----. 1 greatdb greatdb 10555 5月  31 11:17 ib_buffer_pool[#4#root@greatdb81 /greatdb/dbdata/datanode4406/data 15:39:00]4

因为在启动过程中，须要加载ib_buffer_pool文件的内容，还须要到对应数据文件中去读取残缺用户记录，因而启动过程中会有比拟大的IO耗费，但这个复原是由独自的线程异步解决，并不会阻塞MySQL服务的失常启动。

上面比照了开、关参数对系统IO的影响时长，能够看到开启innodb_buffer_pool_load_at_startup=on，零碎IO比拟长的一段时间内处于ioutil为100%的状况

性能补充

MySQL还提供了一些性能，用于满足不同场景下对于innodb_buffer_pool导出、加载的应用

1) 在MySQL运行过程中在线导出

SET GLOBAL innodb_buffer_pool_dump_now=ON;

2) 在MySQL运行过程中手动加载

SET GLOBAL innodb_buffer_pool_load_now=ON;

3) 查看导出进度

SHOW STATUS LIKE 'Innodb_buffer_pool_dump_status';

4) 查看加载进度

SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';

4) 终止以后ib_buffer_pool加载

SET GLOBAL innodb_buffer_pool_load_abort=ON;

5) 在数据库启动的error日志文件中，也有如下信息记录ib_buffer_pool加载动作

结束语

在MySQL启动过程中，因为有innodb_buffer_pool的load，能够让实例在端工夫内复原到重启前的状态，对于数据库系统的稳固有比拟大的作用，然而因为加载须要耗费大量IO，可能会引起IO相干的问题，这是须要留神的。

进行MySQL，倡议按失常命令执行shutdown，十分不举荐应用kill -9(我因为这个操作弄坏的数据库实例也不是一个两个了)。

整顿过程中不免有错漏，还请各位同学多多包涵、多多指导。

最初附上参考资料

https://dev.mysql.com/doc/ref...
https://dev.mysql.com/doc/ref...

Enjoy GreatSQL :)

文章举荐：

面向金融级利用的GreatSQL正式开源
https://mp.weixin.qq.com/s/cI...

Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qc...

MGR及GreatSQL资源汇总
https://mp.weixin.qq.com/s/qX...

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6...

在Linux下源码编译装置GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZ...

# 对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr...

GitHub:

https://github.com/GreatSQL/G...

Bilibili：

https://space.bilibili.com/13...

微信&QQ群：

可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！