Runbook #22

mysql

PerformanceSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsSUPER / CONNECTION_ADMIN / RELOAD / REPLICATION CLIENT

MySQL InnoDB Redo Log Beklemeleri: Log Buffer ve Disk Darboğazı

Innodb_log_waits artışının log buffer sınırı mı yoksa depolama baskısı mı olduğunu ayırır; veri dayanıklılığını bozmadan seçenekleri sıralar.

İlişkili Metrik:M22

İlişkili Script:S39 S27

#innodb#redo-log#innodb_log_waits#disk-io

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M22 (`Innodb_log_waits`) artıyor, commit/yazma gecikmeleri yükseliyor. Sayaç kümülatif olduğu için farkını hesaplayın.

2. Etki / 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. Teşhis / Diagnosis

🟢 Salt Okunur1. Aynı sunucuda iki zaman noktasında ölçün:

sql

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.

🟢 Salt Okunur2. S39 ile I/O yoğun dosyaları inceleyin; OS `iostat -x` ile redo disk yazma gecikmesini ve boş alanını doğrulayın. S27 ile buffer pool isabetini ve bellek baskısını karşılaştırın.

🟢 Salt Okunur3. Büyük transaction, bulk import ve eşzamanlı yazma artışı aynı zamana mı rastlıyor; sorgu ve uygulama yayınlarını denetleyin.

4. Müdahale / Response

🟡 Geri Alınabilir1. Büyük yazma batch'lerini küçültün ve hız sınırlaması koyun; disk kapasitesi/IOPS yetersizse güvenli kapasite artırımı planlayın.

🟡 Geri Alınabilir2. `innodb_log_buffer_size` değerini mevcut değer, büyük transaction hacmi ve RAM payına göre yapılandırmada artırıp **kontrollü yeniden başlatma** ile uygulayın. 5.7/8.0 sürümünde dinamik olduğunu varsaymayın; `SHOW GLOBAL VARIABLES` ve değişken dokümantasyonunu doğrulayın.

🟡 Geri Alınabilir3. 8.0.30+ sürümde redo kapasitesini artırmak gerekebilir (`SET GLOBAL innodb_redo_log_capacity = <olculmus_bayt>;`), fakat bunu buffer beklemesi için otomatik reçete saymayın: checkpoint baskısını ve diski ayrıca kanıtlayın.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. Primary'de `innodb_flush_log_at_trx_commit=2` veya `sync_binlog=0` ile dayanıklılığı gevşetmeyi varsayılan acil çözüm yapmayın; crash sonrası onaylanmış işlemler kaybolabilir.

5. Doğrulama / Verification

- 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. Geri Alma / Rollback

- 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.

Operasyonel Güvenlik ve Risk Uyarısı

1. Belirti / Symptom

2. Etki / Impact

3. Teşhis / Diagnosis

4. Müdahale / Response

5. Doğrulama / Verification

6. Geri Alma / Rollback

Diğer MYSQL Runbook'ları

MySQL 'Too many connections' (Error 1040) Hatası: Teşhis ve Çözüm

MySQL Replikasyon Gecikmesi: Neden Gecikiyor ve Nasıl Kapatılır?

MySQL Yüksek Threads_running ve CPU: Sorgu mu Kilit mi?

MySQL InnoDB Buffer Pool İsabet Oranı Düştü: Bellek ve I/O Triyajı