GTID中MySQL启动时间慢是啥原由
发布时间：2022-01-16 07:37:40 所属栏目：MySql教程 来源：互联网
导读：本篇内容介绍了GTID中MySQL启动时间慢是什么原因的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！ 我们如何找到问题 我们正在研究在启用GTID模式的低
|
本篇内容介绍了“GTID中MySQL启动时间慢是什么原因”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！ 我们如何找到问题 我们正在研究在启用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恢复时间。 “GTID中MySQL启动时间慢是什么原因”的内容就介绍到这里了，感谢大家的阅读。 （编辑：源码门户网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐