MySQL InnoDB Redo Log Waits: Log Buffer and Storage Bottlenecks
Distinguishes log-buffer limits from storage pressure behind rising Innodb_log_waits without compromising durability.
Operational Safety & Risk Notice
This runbook contains operational intervention steps; several are write-impacting (KILL, terminate, DROP, RESIZE). Verify in a staging environment first, and apply sequentially in production with verification.
1. Symptom & Signals
- M22 (`Innodb_log_waits`) artıyor, commit/yazma gecikmeleri yükseliyor. Sayaç kümülatif olduğu için farkını hesaplayın.
2. Business & Technical Impact
Yazmalar bekler; yoğun yükte uygulama timeout'ları ve bağlantı birikimi gelişebilir. `Innodb_log_waits`, redo **log buffer'ın dolup flush beklenmesini** sayar, tek başına redo dosyasının dolduğunu göstermez.
3. Diagnosis & Root-Cause Analysis
SHOW GLOBAL STATUS WHERE Variable_name IN
('Innodb_log_waits','Innodb_os_log_written','Innodb_os_log_fsyncs','Uptime');
SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_log_buffer_size','innodb_flush_log_at_trx_commit','sync_binlog','innodb_redo_log_capacity','innodb_log_file_size');8.0.30+ `innodb_redo_log_capacity`, daha eski sürümlerde `innodb_log_file_size`/`innodb_log_files_in_group` geçerlidir.
4. Remediation & Action Plan
5. Verification & Health Checks
- M22 artış hızı normale iner; commit p95, redo disk gecikmesi ve uygulama hata oranı iyileşir.
- Dayanıklılık ayarları başlangıç değerlerinde ve replica gecikmesi normaldir.
6. Rollback & Contingency Plan
- Log buffer boyutu değiştiyse eski yapılandırmayı geri yükleyip planlı yeniden başlatın.
- 8.0.30+ dinamik redo kapasitesi değiştirildiyse önceki değere dönmeden önce mevcut redo kullanımı ve disk boşluğunu kontrol edin.