In this article, I will provide some advice on how to set MySQL innodb_log_file_sizeparameters .
Like other database management systems, MySQL implements data persistence through logs (on the premise of using the InnoDB storage engine). This ensures that when a transaction commits, its associated data is not lost in the event of a crash or server power loss.
MySQL's InnoDB storage engine uses a Redo log space (a circular data structure) of a specified size. The space of the Redo log is adjusted by the innodb_log_file_sizeand innodb_log_files_in_group(default 2) parameters. Multiply these two parameters to get the total available Redo log space. Although technically it doesn't matter if you adjust the Redo log space via innodb_log_file_sizeor innodb_log_files_in_group, in most cases it is innodb_log_file_sizeadjusted via .
Setting the appropriate Redo log space for the InnoDB engine is very important for write-sensitive workloads. However, this work comes with trade-offs. The more Redo space you configure, the better InnoDB can optimize write operations; however, increasing the Redo space also means longer recovery times in the event of a crash or power outage.
Regarding recovery time, it is not easy to predict how long it will take to recover from a crash for a specified innodb_log_file_size value - it depends on factors such as hardware capabilities, MySQL version, and workload. However, in general, we can estimate the recovery time per 1GB of Redo log to be about 5 minutes. If recovery time is important to your usage environment, I suggest you do some simulation tests to simulate a system crash under normal workload (after warm-up) to evaluate a more accurate recovery time.
While recovery time can be used as a reference factor to limit innodb_log_file_size, there are other ways to see if this parameter setting is "reasonable" (especially if you have PMM installed: Percona Monitoring and Management )
Check the "MySQL InnoDB Metrics" dashboard of Percona Monitoring and Management, if you see the following image: 
Uncheckpointed Bytes is very close to Max Checkpoint Age, then you can almost be sure that the current innodb_log_file_size value is somehow too small Limited system performance. Increasing this value can significantly improve system performance.
And if you see something like the following picture: 
In this picture, Uncheckpointed Bytes is much smaller than Max Checkpoint Age. In this case, increasing innodb_log_file_size will not have a significant performance improvement.
Note: Many MySQL settings are interrelated, and while a particular Redo log space may be sufficient for a small InnoDB Buffer Pool value, a larger InnoDB Buffer Pool value expects a larger Redo log space to achieve better performance.
Another thing to keep in mind: The recovery time we said earlier depends on Uncheckpointed Bytes not the total Redo log space. If you do not observe an increase in recovery time after increasing innodb_log_file_size, it may be that the previous configuration is sufficient for your current workload and the space you increased is not fully utilized.
Another way to look at innodb_log_file_size is the Redo log space usage: 
this image shows the total amount of data written to the log file per hour and the value of innodb_log_file_size. In the above picture, we have 2G of Redo log space but more than 12G of data is written to the log file every hour. This means that the Redo space rotates roughly every ten minutes.
InnoDB flushes every dirty page in the innodb buffer pool to disk every time the Redo log space rotates. InnoDB performs better (and wears less hard drive) when this operation occurs less frequently. I'd like to see this done at least once every 15 minutes, the less the better.
Regarding the usage of Redo space, if PMM is not installed, you can also use the following command to observe the amount of writes per hour (MB):
a=$(mysql -uuser -p'passwd' -e "show engine innodb status\G" | grep "Log sequence number" | awk '{print $4}'); sleep 60; b=$(mysql -uuser -p'passwd' -e "show engine innodb status\G" | grep "Log sequence number" | awk '{print $4}'); let "res=($b-$a)*60/1024/1024";echo $resSummary:
Setting a proper innodb_log_file_file_size is very important to balance performance and recovery time. But keep in mind that the recovery time in your scenario cannot be completely accurately estimated due to various factors. I hope the points discussed in this article will help you set a more reasonable innodb_log_file_file_size.