在这篇博文中，我将提供一些关于如何选择MySQL innodb_log_file_size的指导。
和许多数据库管理系统一样，MySQL使用日志来实现数据的持久性(当使用默认的InnoDB存储引擎时)。这确保在提交事务时，数据不会在崩溃或断电时丢失。
MySQL的InnoDB存储引擎使用固定大小(循环)的重做日志空间。大小由 innodb_log_file_size和innodb_log_files_in_group(默认为2)控制。你将这些值相乘，得到可用的重做日志空间。从技术上讲，不管你是改变innodb_log_file_size还是 innodb_log_files_in_group变量来控制重做空间大小，大多数人都只使用innodb_log_file_size变量，而不使用 innodb_log_files_in_group变量。
对于写密集型工作负载，配置InnoDB的重做空间大小是最重要的配置选项之一。然而，这也伴随着一些权衡。你配置的重做空间越多，InnoDB对写IO的优化就越好。然而，增加Redo空间也意味着当系统断电或因其他原因崩溃时，恢复时间更长。
要预测一个特定的innodb_log_file_size值在系统崩溃时需要多长时间恢复并不容易，这取决于硬件、MySQL版本和工作负载。它可能相差很大(根据情况，相差10倍或更多)。然而，每1GB的innodb_log_file_size大约需要5分钟，这是一个不错的大概数字。如果这对您的环境真的很重要，我建议在满载的情况下(在数据库完全预热之后)模拟系统崩溃来测试它。
虽然恢复时间可以作为InnoDB日志文件大小限制的指导原则，但你可以通过其他方式查看这个数字——特别是如果你安装了Percona Monitoring and Management。
检查Percona监控和管理的“MySQL InnoDB指标”仪表盘。如果你看到这样的图表:
当uncheckpoint Bytes非常接近最大检查点年龄时，你几乎可以确定你当前的innodb_log_file_size限制了系统的性能。增加它可以提供实质性的性能改进。
如果你看到这样的东西:
uncheckpoint Bytes的数量远低于Max Checkpoint Age，那么增加日志文件大小不会给你带来显著的改进。
注意:许多MySQL设置是相互连接的。虽然特定的日志文件大小对于较小的innodb_buffer_pool_size可能已经足够了，但更大的InnoDB缓冲池值可能需要更大的日志文件以获得最佳性能。
另一件需要记住的事情是:我们之前谈到的恢复时间实际上取决于uncheckpoint Bytes，而不是总日志文件大小。如果你没有看到更大的innodb_log_file_size的恢复时间增加，请查看InnoDB检查点年龄图——这可能是因为你不能在你的工作负载和配置中充分利用大的日志文件。
查看日志文件大小的另一种方法是在日志空间使用的上下文中:
这张图显示了每小时写入InnoDB日志文件的数据量，以及InnoDB日志文件的总大小。在上面的图中，我们有2GB的日志空间，每小时有12GB的日志文件被写入。这意味着我们每十分钟循环查看一次日志。
InnoDB必须在每个日志文件周期内至少刷新缓冲池中的脏页一次。
InnoDB在这样做的频率越低，性能就越好，而且SSD设备的损耗也越小。我希望这个数字不少于15分钟。一个小时更好。
总结
获取innodb_log_file_file大小对于在相当快的崩溃恢复时间和良好的系统性能之间取得平衡很重要。记住，你的恢复时间目标并不像你想象的那么琐碎。我希望这篇文章中描述的技巧能帮助你找到最适合你的情况的价值!
