MySQL在崩溃恢复过程中使用内部重做日志来纠正不完整事务写入的数据。但是如何知道正确的重做日志大小呢?我们将在这篇博客中讨论如何解决这个问题。

我们已经有了一些与这个主题相关的帖子。”如何计算一个好的InnoDB日志文件大小"和"如何选择MySQL innodb_log_file_size第一个有我将在这个博客中提到的公式，第二个有关于重做日志的更多细节。大部分仍然有效，只需替换即可Innodb_log_file_size / innodb_log_files_in_group . txt与innodb_redo_log_capacity．

在这篇文章中，我想重点讲两件事:

  1. 介绍处理重做日志的新方法(不再innodb_log_file_size/innodb_log_files_in_group）.
  2. 验证公式输出，并将其与从中获得的信息进行比较雷竞技下载官网Percona管理和监控(PMM)raybet雷竞技竞猜在线官网．

第二点的TL;DR是:

  • 如果你想要一个快速(不一定正确)的答案，你仍然可以使用这个公式。
  • 如果您希望得到基于数据库使用和模式的详细信息的答案，建议使用Percona Management and Monitoring。雷竞技下载官网raybet雷竞技竞猜在线官网

包含相关信息的PMM图(在MySQL / InnoDB Details / InnoDB Logging):

  • 重做生成速率。
  • InnoDB日志文件使用率每小时。

公式:

注意:这个公式来自上面提到的第一篇文章;它用来查看在一分钟内有多少MB被写入日志。

重做日志

从MySQL 8.0.30开始，应该优化重做日志的变量是innodb_redo_log_capacity，我们从好消息开始:它是动态的!因此，如果需要调优，您将不会有停机时间。

8.0.30之前的MySQL版本:

innodb_log_file_size而且innodb_log_files_in_group：

默认情况下，InnoDB会在data目录下创建两个重做日志文件(innodb_log_files_in_group)，分别命名为ib_logfile0和ib_logfile1，并循环写入这些文件;大小都是innodb_log_file_size．

MySQL 8.0.30及以上版本:

innodb_redo_log_capacity

InnoDB创建32个文件(每个文件的大小为Innodb_redo_log_capacity / 32)在# innodb_redo数据目录中的目录，除非innodb_log_group_home_dir变量指定了不同的目录。

那么，有了新变量后，如何计算值呢?

  1. 如果innodb_redo_log_capacity配置，这是使用的值(忽略innodb_log_file_size而且innodb_log_files_in_group）.
  2. 如果innodb_redo_log_capacity还没定，可是innodb_log_file_size而且innodb_log_files_in_group， MySQL将计算值(innodb_log_files_in_group＊innodb_log_file_size＝innodb_redo_log_capacity）.
  3. 如果没有配置，则重做日志容量设置为innodb_redo_log_capacity默认值(100mb)。

提醒一下为什么要调优:如果重做日志已满，MySQL必须执行检查点(从InnoDB缓冲池刷新到磁盘)。如果你的重做日志很小，检查点会更频繁地发生，增加更多的I/O并影响性能。

这里的一个经验法则是将重做日志配置为能够容纳一个小时的流量，从而让检查点以一种平稳、不那么激进的方式执行。否则，由于检查点不可避免，刷新可能发生在最糟糕的时间。

测试公式

为了有一个大概的概念，我在一个循环中执行了一些基本的mysqlslap命令来在数据库中创建负载。这远非一个真实的场景测试，但它应该在这个特定的情况下对我们有所帮助。

测试第一篇博文中分享的“经验法则公式”:

我又测试了几次，结果如下:

我们可以看到，在负载一致的情况下，经验法则给出的平均值为每分钟63.8兆字节(3.74 GB /小时)．

这是可行的，但它是手动的，并且您需要在线并在高峰时段运行几次。

使用PMM

在PMM中，您可以找到许多有用的图表，在本博客中，我将重点介绍这些图表MySQL / InnoDB详细信息/ InnoDB日志。

我想指出的第一个图表是重做生成率。我筛选了mysqlslap在循环上运行时的时间框架，值为1.1 MB/s(我们可以推断为每分钟66mb或每小时3.87 GB，与上式结果基本一致)。

重做生成率

也就是说，你可以通过这个图表来更好地了解有多少重做正在被创建，并且你不需要使用命令和手动检查负载何时正在运行，你可以稍后检查它，甚至在特定的时间框架内检查它。例如，如果你最大的负载发生在周末，你不希望只是为了计算正确的设置而在线。

在PMM中还有另一个图表可以用来检查数据库中重做日志的每小时使用情况:InnoDB日志文件每小时使用情况;在这一个，你可以看到过去24小时的模式，第一眼看到它，如果你需要增加/减少你的设置。

InnoDB日志文件使用率

注意:我已经截断了过去24小时的图表，以避免图像在这里太小。

请查看上图中20:00左右的峰值，这与mysqlslap“积极”运行的时间相匹配。如果你一直在计算，它与其他两个检查相匹配:

  • 经验法则公式:63.8 MB /分钟= 3.74 GB /小时。
  • 重做生成速率:1.1 MB /秒= 66 MB /分钟= 3.87 GB /小时
  • InnoDB日志文件使用率每小时:4GB /小时。

结论

即使变量最近发生了变化，你仍然需要监视和配置你的重做日志，特别是对于写量大的环境;raybet雷竞技竞猜在线官网要做到这一点，您仍然可以使用公式，或者您可以利用PMM图形。

这个公式可以作为第一步，但可能会导致过度配置(或配置不足)重做日志。

与MySQL中的所有内容一样，在执行更改之前，您对环境的信息越多，结果就越好。这就是为什么我建议更进一步，用PMM检查细节。如果您还没有使用PMM，它是开源的，您可以快速安装并开始使用它。查看我们的PMM快速入门而且如果您有任何问题或问题，请在论坛中与我们交谈．

雷竞技下载官网Percona Distribution for MySQL是最完整、稳定、可扩展和安全的开源MySQL解决方案，为您最关键的业务应用程序提供企业级数据库环境……而且它是免费使用的!

现在就试雷竞技下载官网试MySQL的Percona发行版吧!