- 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 公布!