mysql二进制日志时间_GTID中MySQL启动时间慢？二进制日志文件大小可能是问题

您是否在GTID模式下遇到MySQL启动时间较慢的问题？我们最近在我们的一个MySQL托管部署中遇到了这个问题，并着手解决这个问题。在本文中，我们分解了可能会减慢MySQL重启时间，如何调试部署以及如何减少启动时间和提高对基于GTID的复制的理解的问题。

我们如何找到问题

我们正在研究在启用GTID模式的低端，基于磁盘的MySQL 5.7.21部署中缓慢的MySQL启动时间。该系统是主从对的一部分，并且处于适度的写入负载下。在计划维护期间重新启动时，我们注意到数据库服务器需要5-10分钟才能启动并开始接受连接。这种延迟没有意义，所以我们开始调查。

调试慢速MySQL启动时间

我们使用流行的Percona工具pt-ioprofile来查看数据库正在做什么。pt-ioprofile是Percona 用于调试MySQL问题的流行工具包中非常重要的实用程序，您可以在其文档中看到完整的功能列表。pt-ioprofile工具使用strace和lsof来监视进程的I / O并打印出一个文件和I / O活动表。

所以，我们启动MySQL，等待mysqld进程生成，并启动pt-ioprofile以查看问题可能是：

＃ PT - ioprofile  - 个人资料- 过程 的mysqld  - 运行- 时间 200

周二 年10月 9  15：42：24  UTC  2018

跟踪 进程 ID  18677

total       pread        read      pwrite       write       fsync   fdatasync        open       close    getdents       lseek       fcntl  filename

...

216.550641    0.000000   216.550565    0.000000    0.000000    0.000000    0.000000    0.000015    0.000040    0.000000    0.000021    0.000000  / mysql_data / binlogs / mysql - bin。000014

...

你的MySQL重启的原因是什么？

在多次运行时，我们观察到以下情况：

mysqld进程大部分时间都在阅读最新的二进制日志文件。即使服务器已经正常停止并且不需要崩溃恢复等，情况也是如此。

服务器也花了相当多的时间加载InnoDB数据文件，但与读取最新的二进制日志文件所花费的时间相比，这个时间要小得多。

如果服务器立即重新启动，则后续重启会更快。

由于数据库关闭会刷新二进制日志并在启动时创建一个新日志，因此我们进行了另一项实验 - 在关闭服务器之前，我们刷新了二进制日志。后续服务器启动再次快速。

这些观察清楚地指出MySQL正在花费大量时间阅读最新的二进制日志文件。如果文件很小，就像在关机之前刷新日志文件那样，启动速度很快。

了解Binlog GTID恢复

事实证明，为了填充gtid_executed和gtid_purged的值，MySQL服务器必须解析二进制日志文件。

以下是基于FALSE或TRUE读数的MySQL 5.7 文档方法建议的摘要：

当

binlog_gtid_simple_recovery

= FALSE时：

要计算

gtid_executed：

从最新的迭代二进制日志文件，停止在具有

Previous_gtids_log_event

条目的第一个文件。

从此二进制日志文件中使用

Previous_gtids_log_event

和

Gtid_log_events中的

所有GTID ，并在内部存储此GTID集。它被称为

gtids_in_binlog。

价值

gtid_executed

被计算为工会

gtids_in_binlog

并在该GTIDs

mysql.gtid_executed表

。

如果存在大量没有GTID的二进制日志文件(例如，在

gtid_mode

= OFF 时创建)，则此过程可能非常耗时。

同样，要计算

gtid_purged：

迭代从最旧到最新的二进制日志文件，停止在包含非空的

Previous_gtids_log_event

(至少有一个GTID)或至少有一个

Gtid_log_event

的第一个二进制日志中。

从此文件中读取

Previous_gtids_log_event

。计算内部变量

gtids_in_binlog_not_purged，

因为此

gTID

集从

gtids_in_binlog中

减去

。

价值

gtid_purged

设置为

gtid_executed

，减去

gtids_in_binlog_not_purged

。

因此，这构成了我们理解旧版本中工作原理的基础。但是，当

binlog_gtid_simple_recovery

为TRUE 时，可以进行某些优化。我们感兴趣的是这种情况：

当

binlog_gtid_simple_recovery

= TRUE时：

(注意，这是MySQL 5.7.7及更高版本中的默认设置)

只读最旧和最新的二进制日志文件。

从最早的二进制日志文件中找到的

Previous_gtids_log_event

或

Gtid_log_event

计算

gtid_purged

。

从最新的二进制日志文件中找到的

Previous_gtids_log_event

或

Gtid_log_event

计算

gtid_executed

。

因此，在服务器重新启动或清除二进制日志期间，

只

读取

两个二进制日志文件

。

因此，对于MySQL 5.7.7及更高版本，在系统启动期间始终读取最新和旧的二进制日志文件，以正确初始化GTID系统变量。读取最旧的二进制日志文件并不昂贵，因为MySQL正在寻找的事件，Previous_gtids_log_event，始终是二进制日志文件中的第一个事件。

但是，为了正确计算gtid_executed，服务器必须读取整个最新的二进制日志文件并收集该文件中的所有事件。因此，系统启动时间与最新二进制日志文件的大小成正比。

请注意，当binlog_gtid_simple_recovery为FALSE 时，情况会更糟。由于它不再是最近版本中的默认选项，因此并不是一个值得关注的问题。

如何解决您的慢启动时间

了解了我们遇到的问题的原因，我们决定的解决方案相当明显 - 减少二进制日志文件的大小。二进制日志文件的默认大小为1GB。在启动期间解析此大小的文件需要花费时间，因此将max_binlog_size的值减小到较低值是有意义的。

如果不能减小二进制日志文件的大小，那么在维护关闭mysqld进程之前刷新二进制日志文件有助于减少binlog GTID恢复时间。