dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #23
mysql
CapacitySEV1 · CRITICAL OUTAGE15-30 dakika / 15-30 minsSUPER / CONNECTION_ADMIN / RELOAD / REPLICATION CLIENT

MySQL Binary Log Disk Filling Up: Protect Replicas and PITR

Checks replica requirements and point-in-time recovery retention before safe purging and capacity actions as binlog disk space runs low.

Related Metrics:M23
Related Scripts:S38S23
#binlog#purge#replication#pitr

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.

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

1. Symptom & Signals

- M23 artar; binlog dizininde boş alan <%20/%10. Yazmada `errno 28 No space left on device` veya binlog yazma hatası görülebilir.

2. Business & Technical Impact

Disk tamamen dolarsa yeni transaction ve binlog yazımı durur. Gereğinden erken purge, geride kalan replica'yı ve PITR (anlık zamana kurtarma) zincirini bozabilir.

3. Diagnosis & Root-Cause Analysis

🟢 Read-Only1. S38 ile log listesi ve saklama ayarı:
sql
SHOW BINARY LOGS;
SHOW GLOBAL VARIABLES LIKE 'log_bin_basename';
SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_seconds';  -- 8.0
SHOW GLOBAL VARIABLES LIKE 'expire_logs_days';          -- 5.7

OS'te `log_bin_basename` dizinini `df -h` ile ölçün. İlgili yapılandırma sürümde mevcut değilse satır dönmez.

🟢 Read-Only2. **Her replica** üzerinde replikasyon konumunu ve gecikmesini kaydedin:
sql
SHOW REPLICA STATUS\G  -- 8.0.22+; 5.7 / eski 8.0: SHOW SLAVE STATUS\G

`Relay_Source_Log_File` (eski adı `Relay_Master_Log_File`) ve `Source_Log_File`/`Master_Log_File` alanlarını, GTID durumunu gözden geçirin. Gecikme/bağlantı kesilmesi varsa kaynağın hangi binlog'una hâlâ ihtiyaç duyulduğunu **replica konumundan** doğrulayın.

🟢 Read-Only3. PITR gereksinimini ve harici binlog arşiv/yedeklerini doğrulayın; yalnızca replika durumu yeterli değildir. S23 ile hangi şema/tablo büyümesi yazma hacmini artırdı inceleyin.

4. Remediation & Action Plan

🟡 Reversible1. Öncelikle binlog mount kapasitesini güvenli şekilde genişletin veya uygulamada yüksek hacimli yazmayı kontrollü yavaşlatın. Yedekleme/arka plan işlerindeki atık dosyaları yalnızca sahibiyle doğruladıktan sonra temizleyin.
🔴 HIGH RISK / IRREVERSIBLE2. **Tüm replica ve yedek/PITR penceresinden artık gerekmeyen** dosyalar için MySQL içinde purge yapın; örnekte adı geçen dosya korunur, **öncekiler** silinir:
sql
PURGE BINARY LOGS TO 'mysql-bin.000123';

Gerçek binlog adını `SHOW BINARY LOGS` çıktısından, en eski güvenli sınırı tüm replica konumları ile yedek politikasından belirleyin. MySQL hata verirse zorlamayın.

🟡 Reversible3. Kalıcı saklama süresini mevcut PITR ve replika kesinti hedeflerini karşılayacak şekilde ayarlayın: 8.0'da `binlog_expire_logs_seconds`, 5.7'de `expire_logs_days` (yapılandırma dosyası ve uygun sürümde dinamik ayar); ayarı düşürmek otomatik purge sırasında log kaybına yol açabileceği için ancak yedek doğrulaması sonrası uygulayın.
🔴 HIGH RISK / IRREVERSIBLE4. Binlog dosyalarını **`rm` ile silmeyin**, `RESET MASTER`/`RESET BINARY LOGS AND GTIDS` komutlarını alan açmak için kullanmayın, replica/PITR zincirini bozabilir. `log_bin=OFF` bir çözüme dönüştürülmemelidir.

5. Verification & Health Checks

- İlgili filesystem boş alanı güvenli seviyede; yeni transaction yazabiliyor.

- Tüm replica'ların IO/SQL thread'leri çalışıyor ve gerekli binlog'lar mevcut; yedek/restore zinciri korunuyor.

6. Rollback & Contingency Plan

- `PURGE BINARY LOGS` geri alınamaz. Silmeden önce doğrulanmış arşiv/yedek yoksa replica'nın yeniden kurulması gerekebilir.

- Geçici yazma hız sınırını ve saklama ayarını onaylı hedefe döndürün.

More MYSQL Runbooks