InnoDB records each change in the sequential redo log and writes dirty pages later; recovery replays it from the last checkpoint. Too small a log forces early flushing in write bursts; a large one lengthens recovery. Since 8.0.30 the dynamic innodb_redo_log_capacity (default 100 MB) sizes it across 32 files in #innodb_redo/; in 9.7 innodb_log_file_size and innodb_log_files_in_group are gone (ERROR 1193). A SET GLOBAL to 4 GB took effect without a restart (Innodb_redo_log_resize_status read OK). A common target is one peak hour of redo: sample Innodb_redo_log_current_lsn an hour apart.
How often the redo log and the binary log (on by default) reach disk is a durability choice. Eight mysqlslap clients ran 16,000 single-row autocommit inserts under each pair:
| trx_commit / sync_binlog | Flushing | A crash can lose | Run time |
|---|---|---|---|
| 1 / 1 (default) | fsync redo and binlog at every commit | Nothing committed | 33.4 s |
| 2 / 1 | Redo written at commit, fsynced each second | ~1 s if the OS fails | 17.4 s |
| 2 / 0 | Binlog fsync left to the OS | ~1 s plus binlog events | 1.5 s |
| 0 / 0 | Redo written and fsynced each second | ~1 s even if mysqld dies | 1.1 s |
Relaxing both was 30 times faster; the binlog fsync was half the cost. WSL2's virtual disk has slow fsync, so measure your hardware. Keep 1/1 for orders and payments (ACID); use 2/0 only for data you can reload. Fewer, larger transactions also cut fsyncs.