dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #24
mysql
AvailabilitySEV1 · KRİTİK KESİNTİ15-30 dakika / 15-30 minsSUPER / CONNECTION_ADMIN / RELOAD / REPLICATION CLIENT

MySQL Veri Diski Doldu: Güvenli Alan Açma ve Servisi Kurtarma

Disk dolmasının veri, binlog, temp veya yedek kaynaklı olduğunu ayırır; kurtarma zincirini bozmadan alan açma ve doğrulama planı sunar.

İlişkili Metrik:M24
İlişkili Script:S23S34S37S38
#disk-full#capacity#binlog#innodb

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

- M24 kritik (<%10 boş), MySQL error log'da `No space left on device`/errno 28; yazma, geçici tablo veya binlog işlemleri başarısız.

2. Etki / Impact

Yazmalar durabilir, replika gecikebilir; temp alanı dolarsa sorgular hata verir. Ani restart, kurtarma için gereken boş alan yoksa açılmayı da engelleyebilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. MySQL'in dosya konumlarını ve diskleri doğrulayın:
sql
SHOW GLOBAL VARIABLES WHERE Variable_name IN
 ('datadir','tmpdir','log_bin_basename','innodb_data_home_dir');
SHOW BINARY LOGS;
bash
df -h /var/lib/mysql /tmp

Yollar ve mount'lar örnektir; `datadir`/`tmpdir` çıktısındaki gerçek yolları OS'te kontrol edin. Ayrıca inode doluluğunu `df -i` ile bakın.

🟢 Salt Okunur2. S23/S34 ile büyük tablo ve şemaları; S37 ile veri/boş alan tahminini; S38 ile binlog hacmini bulun. Error log, uygulama dump'ları, backup ve temp dizinlerinin aynı filesystem'de olup olmadığını kontrol edin.
🟢 Salt Okunur3. `data_free` InnoDB'de her zaman OS'e geri kazanılabilir alan değildir; `OPTIMIZE TABLE` çoğu zaman ek geçici alan gerektirir ve acil durumda ters etki yapar.
🟢 Salt Okunur4. Replica'lar ve PITR yedekleri binlog temizliğinden önce denetlenmelidir (`mysql-binlog-disk-full`).

4. Müdahale / Response

🟡 Geri Alınabilir1. Öncelik: disk/volume'u büyütün veya **MySQL veri dizini dışındaki**, gereksiz ve doğrulanmış uygulama log/yedeklerini aynı mount'tan kontrollü kaldırın/taşıyın. İşlem başlamadan önce yedek ve veri sahipliğini doğrulayın.
🟡 Geri Alınabilir2. Büyük yazma/batch işlemini geçici yavaşlatın; daha fazla alan tüketmesini önleyin.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ3. Binlog kaynaklıysa yalnızca tüm replica ve PITR gereksinimleri doğrulandıktan sonra `mysql-binlog-disk-full` adımlarını izleyin; burada koşulsuz PURGE yapmayın.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. `ibdata1`, `ib_logfile*`, `#innodb_redo`, `.ibd`, `undo*` veya aktif binlog'u OS'ten **silmeyin/taşımayın**. `TRUNCATE`/`DROP` iş verisini yok eder; acil durum için varsayılan çözüm değildir.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ5. Dosya silindikten sonra disk alanı geri gelmediyse açık file descriptor olabilir: `lsof +L1` ile bulun; sırf yer açmak için MySQL'i körlemesine yeniden başlatmayın. Gerekirse kontrollü restart ve kurtarma planını uygulayın.
🟡 Geri Alınabilir6. Alan açıldıktan sonra otomatik büyüme, backup/binlog saklama ve kapasite projeksiyonunu düzeltin.

5. Doğrulama / Verification

- Gerçek data/temp/binlog mount'larında boş alan hedefin üzerine çıktı; inode'lar uygun.

- Uygulamada yazma/okuma başarılı, error log'da yeni disk hatası yok; replica'lar yakaladı.

- Yedek alınabiliyor ve son yedeğin geri yüklenebilirliği doğrulanıyor.

6. Geri Alma / Rollback

- Kaldırılan arşiv/yedekler ve PURGE işlemi geri alınamaz; temizlemeden önce dış kopyayı doğrulayın.

- Geçici batch kısıtını kapasite güvenli hale geldikten sonra kontrollü kaldırın; volume büyütmeyi geri almaya çalışmayın.

Diğer MYSQL Runbook'ları