mysql关闭慢

向右看齐 2023-02-27 10:56 5阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY_size_16_color_FFFFFF_t_70][]  
  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY_size_16_color_FFFFFF_t_70 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY_size_16_color_FFFFFF_t_70 2][]

http://www.orczhou.com/index.php/2010/12/more-about-mysql-innodb-shutdown/  
http://www.orczhou.com/index.php/2014/03/some-tricky-about-mysqladmin-extended-status/  
https://dbarobin.com/2015/08/29/mysql-optimization-under-ssd/  
https://www.percona.com/blog/2016/05/05/percona-server-5-7-multi-threaded-lru-flushing/  
https://yq.aliyun.com/articles/40903?spm=5176.8091938.0.0.b6sdPr  
https://yq.aliyun.com/groups/25  
http://mysql.taobao.org/index.php?title=MySQL%E5%86%85%E6%A0%B8%E6%9C%88%E6%8A%A5\_2015.02  
  
快速关闭MySQL/InnoDB

如果用的引擎是InnoDB，每次敲下mysqladmin -uroot -p shutdown关闭数据库的时候，总是很难预测这个命令会执行多久，实际经验表明，短则五秒，长则三十分钟一小时都有可能。也分享一下我的经验吧。

1. 为什么InnoDB关闭会慢？

事实上，并不是每次关闭InnoDB都很慢的。Why？InnoDB较之MyISAM，一个重要特性是InnoDB会在内存中开辟一个Buffer Pool来存储最近访问的数据块/索引块，使得下次再次访问这个块时速度能够很快。当InnoDB对需要修改数据块的时候，会先记录修改日志，然后直接对Buffer\_Pool中的数据块的操作。记录日志是顺序写，对数据块的操作是内存操作，这让InnoDB在很多场景下有这很好的速度优势。

上面对内存块修改完成后，InnoDB就向客户端返回了。可这时实际磁盘上的数据块，还并没有被更新，我们把这样的page称为Dirty Page。在InnoDB的后台有一个专门的线程来做将内存数据块Flush到磁盘的工作。这个Flush操作就是主要影响InnoDB关闭时间的因素。在关闭MySQL/InnoDB时，所有的Dirty\_Page都需要Flush，所以Dirty\_Page越多，要Flush的数据块也就越多，意味着InnoDB关闭时间越长。

我们可以通过下面的命令来观察Dirty Page的数量：

mysqladmin -uroot ext -i 1 |grep "Innodb\_buffer\_pool\_pages\_dirty"

2. 参数innodb\_max\_dirty\_pages\_pct

Buffer\_Pool中Dirty\_Page所占的数量，直接影响InnoDB的关闭时间。参数innodb\_max\_dirty\_pages\_pct可以直接控制了Dirty\_Page在Buffer\_Pool中所占的比率，而且幸运的是innodb\_max\_dirty\_pages\_pct是可以动态改变的。

所以，在关闭InnoDB之前先将innodb\_max\_dirty\_pages\_pct调小，强制数据块Flush一段时间，则能够大大缩短MySQL关闭的时间。

set global innodb\_max\_dirty\_pages\_pct=0;

一般执行了上面的命令之后，Dirty\_Page的Flush仍需要一段时间，所以要稍等一会儿，再关闭MySQL才有效果。

3. 关闭前做些什么

有时候，就算你改变innodb\_max\_dirty\_pages\_pct=0，仍然不能保证InnoDB快速关闭。还有一些注意事项。

设置数据库为只读：如果数据库一直是活跃的，有连接在向里面写数据，那么Dirty Page则还可能不断的产生。

如果是备库，在innodb\_max\_dirty\_pages\_pct设置成0的同时，最好先stop slave：这个很关键，而且对关闭时间影响也会很大。第一，主动stop slave后，MySQL在关闭时，需要停止的线程其实是更少了的。第二，如果slave的SQL线程还在执行的话，Buffer Pool则还在活动，Dirty Page也可能还会不断的增多。

一般，如果注意到了上面三点：

set global innodb\_max\_dirty\_pages\_pct=0

set global read\_only=1

stop slave

关闭数据库，就会很快了。如果你把上面三步做完，然后观察Dirty Page的数量，当数量很少时，再执行命令关库，这样总能保证以较快的速度完成关库命令。

4. 一个注意事项

这里需要注意的是，你不需等到Dirty Page的数量到零，才开始关闭MySQL。因为有时候，即使已经没有活动的会话时，InnoDB的Insert Buffer的合并仍然会产生一些Dirty Page，所以这时你可能会发现，等了很久很久很久Dirty Page的数量仍然大于零。

其实这时，你已经可以快速的关闭数据库了。我怎么判断这种情况呢？这时我们可以通过InnoDB的LSN来判断，下面是SHOW InnoDB Status里面获取的信息：

Log sequence number 814 3121743145

Log flushed up to   814 3121092043

Last checkpoint at  814 2826361389

这里看到，当前的LSN是814 3121743145，最后一个检查点在814 2826361389，也就是说两者相差了3121743145-2826361389=295381756，那么意味着InnoDB还有很多Dirty Page需要Flush。

下面是另一个库的LSN信息：

Log sequence number 0 1519256161

Log flushed up to   0 1519256161

Last checkpoint at  0 1519256161

可以看到，这里的Dirty Page都已经Flush了，那么关闭InnoDB也就很快了。

一般，并不需要等到最后检查点和当前LSN相等才关闭，两者只要相差不多（<1000）关闭起来就很快了。

5. 最后再罗嗦一下

其实，像上面这样折腾，整个关库的过程有可能并不比你直接执行mysqladmin -uroot shutdown快，但是执行上面的步骤，会让你清楚关库到底与多久，可以让你的关库命令能够在一个可以预期的时间内完成。简单的说，会让关库的时间心里有个底。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY_size_16_color_FFFFFF_t_70]: /images/20230209/4cd37316f3c2426d8598e7f67da1b8a8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200717111711288.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c4OTI4MjQxOTY_size_16_color_FFFFFF_t_70 2]: /images/20230209/4a0e202192da478997d89e4388713325.png