MySQL Diski Doldurdu: binlog, ibdata1 ve Geçici Dosya Temizliği

Saat gecenin biri, siteniz "Error establishing a database connection" veriyor. SSH ile sunucuya bağlanıp df -h yazıyorsunuz ve kök bölüm %100. systemctl start mysql komutu geri dönmüyor, hata günlüğünde InnoDB: Error while writing ... Operating system error number 28 satırı var. 28 numaralı hata ENOSPC, yani "disk üzerinde yer kalmadı".

Bu noktada çoğu kişinin ilk refleksi /var/lib/mysql dizinine girip en büyük dosyaları silmektir. Orası tam olarak felaketin başladığı yerdir: o dizindeki dosyaların bir kısmı gerçekten silinebilir, bir kısmı silinirse replikasyonu geri dönülemez şekilde bozar, bir kısmı ise silinirse veritabanınız bir daha açılmaz. Aynı dizinde yan yana duran binlog.000412, ibdata1 ve ibtmp1 dosyaları tamamen farklı üç sorunu temsil eder ve üçünün çözümü de farklıdır.

Bu yazıda önce sorunun MySQL'den kaynaklanıp kaynaklanmadığını doğrulayacağız, sonra veri dizinindeki dosyaları tek tek tanıyıp hangisinin niçin şiştiğini teşhis edeceğiz. Ardından her biri için doğru temizlik yöntemini, kalıcı önlemleri ve "yaptıysanız artık geri dönüşü yok" tuzaklarını tek tek ele alacağız.

Disk Doldu Ama Suçlu Gerçekten MySQL mi?#

Panik hâlinde veritabanı dosyalarına dokunmadan önce iki dakikalık bir doğrulama yapın. Diski dolduran şey bazen MySQL değil, aynı bölümdeki devasa bir Apache erişim günlüğü ya da unutulmuş bir yedek dosyasıdır.

# Hangi bölüm dolu?
df -h

# Inode tükenmiş olabilir; boş alan varken bile "disk dolu" hatası verir
df -i

# En büyük dizinleri tek seviyede sırala (bölüm sınırını aşma)
du -x -h --max-depth=1 / | sort -h | tail -15
du -x -h --max-depth=1 /var/lib/mysql | sort -h | tail -15

Genel disk dolması senaryolarının tamamı için disk dolu hatasının çözümü yazımız daha geniş bir kontrol listesi sunar; ölçüm araçlarının farkları için de df, du ve ncdu kullanımı rehberine bakabilirsiniz.

Bir tuzağa dikkat: du az yer gösterirken df dolu diyorsa, silinmiş ama hâlâ bir süreç tarafından açık tutulan dosyalar vardır. MySQL bunu sık yapar — birisi çalışan sunucunun altından bir günlük dosyasını rm ile silmiştir, alan ancak süreç kapanınca geri gelir.

# Silinmiş ama açık tutulan dosyaları listele
lsof -nP +L1 2>/dev/null | grep -i mysql

/var/lib/mysql İçindeki Dosyalar Ne İşe Yarıyor?#

Veri dizinini açtığınızda gördüğünüz dosyalar dört farklı kategoriye ayrılır. Aşağıdaki tablo, hangisinin silinebilir, hangisinin dokunulmaz olduğunu özetler:

Kısa yol: adında bin veya log geçen metin/akış dosyaları yönetilebilir; ib ile başlayan her şey InnoDB'nin iç yapısıdır ve elle silinmesi veritabanını kaybetmek demektir.

Hangi kategorinin şiştiğini tek komutla görün:

ls -lhS /var/lib/mysql | head -20

Binary Log (binlog) Nedir, Neden Bu Kadar Büyür?#

Binary log, veritabanında veri değiştiren her işlemin (INSERT, UPDATE, DELETE, DDL) sıralı kaydıdır. İki kritik işi vardır: replikasyonda kopya sunucu bu günlüğü okuyarak ana sunucuyu takip eder ve zaman noktasına geri dönüş (point-in-time recovery) yalnızca bu günlük sayesinde mümkündür. Yani binlog bir "çöp" değildir; kurtarma zincirinizin yarısıdır.

MySQL 8.0 ile birlikte log_bin varsayılan olarak açık geldi ve varsayılan format satır tabanlıdır (binlog_format=ROW). Satır tabanlı formatta UPDATE siparisler SET durum='kapali' gibi tek satırlık bir sorgu, etkilediği milyon satırın öncesini ve sonrasını günlüğe yazar. Bir gecelik toplu güncelleme işi, tek başına onlarca gigabayt binlog üretebilir. En sık karşılaşılan büyüme sebepleri şunlardır:

• Toplu UPDATE/DELETE işleri veya gece çalışan bir veri temizleme betiği
• binlog_row_image=FULL varsayılanı ile geniş satırlı tablolar (BLOB/TEXT sütunları günlüğe iki kez girer)
• Süresi dolmuş günlüklerin hiç temizlenmemesi (5.7'den yükseltilmiş sunucularda expire_logs_days=0 kalmış olması)
• Duran bir replika yüzünden günlüklerin bilerek biriktirilmesi

Ne kadar yer kapladığını ve kaç dosya olduğunu MySQL'e sorun:

SHOW BINARY LOGS;
SHOW VARIABLES LIKE 'log_bin%';
SHOW VARIABLES LIKE 'binlog_expire%';
SHOW VARIABLES LIKE 'max_binlog_size';

Bir günlüğün içinde ne olduğunu merak ediyorsanız, silmeden önce bakabilirsiniz:

mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/binlog.000412 | head -100

Binlog'u Doğru Silmek: rm Değil, PURGE#

İşin en kritik kuralı burada: binlog dosyalarını rm ile silmeyin. MySQL, hangi günlük dosyalarının var olduğunu diskteki dosyalardan değil, binlog.index adlı bir liste dosyasından okur. Dosyayı rm ile silerseniz indeks hâlâ o dosyayı arar; bir sonraki PURGE veya yeniden başlatma sırasında MySQL hata günlüğüne Failed to open log yazar, otomatik temizleme mekanizması kilitlenir ve sorun daha da kötüleşir. Replikasyon varsa kopya sunucu okuyacağı dosyayı bulamaz ve replikasyon kalıcı olarak durur.

Doğru yöntem SQL tarafındadır. İki kullanım şekli vardır:

-- Belirtilen dosyadan ÖNCEKİ tüm günlükleri sil (dosyanın kendisi kalır)
PURGE BINARY LOGS TO 'binlog.000410';

-- Belirli bir tarihten önceki günlükleri sil
PURGE BINARY LOGS BEFORE '2026-08-15 03:00:00';

-- Son 3 günü sakla, gerisini at
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;

PURGE, hem dosyayı diskten siler hem de binlog.index içindeki satırı kaldırır. İki iş tek komutta tutarlı biçimde yapıldığı için güvenlidir.

Replikasyon Varsa Silmeden Önce Bunu Kontrol Edin#

MySQL, o an bağlı bir kopya sunucunun okumakta olduğu günlüğü silmeyi reddeder. Ancak kopya sunucu kapalı, durdurulmuş ya da ağ sorunu yüzünden kopmuşsa bu koruma çalışmaz: ihtiyaç duyduğu dosyayı silersiniz, replika geri geldiğinde Could not find first log file name in binary log index file hatasıyla açılmaz ve replikayı sıfırdan kurmak zorunda kalırsınız.

Bu yüzden her kopya sunucuda önce şunu çalıştırın ve hangi dosyada olduklarını not edin:

-- MySQL 8.0.22 ve sonrası
SHOW REPLICA STATUS\G
-- Bakılacak alanlar: Source_Log_File, Relay_Source_Log_File, Seconds_Behind_Source

-- MySQL 5.7 / MariaDB
SHOW SLAVE STATUS\G
-- Bakılacak alanlar: Master_Log_File, Relay_Master_Log_File

En geride kalan replikanın okuduğu dosya binlog.000398 ise, PURGE BINARY LOGS TO 'binlog.000398' sınırınızdır; bir dosya bile ötesine geçmeyin. Replikasyon topolojisinin nasıl kurulduğu ve kopanın nasıl geri alındığı konusunda MySQL replikasyon kurulumu yazısı ayrıntılı bir referanstır.

Ayrıca PURGE çalıştırmadan önce zaman noktasına dönüş ihtiyacınızı düşünün: son tam yedeğiniz üç gün öncesine aitse ve üç günlük binlog'u silerseniz, o üç güne artık geri dönemezsiniz. Yedek stratejinizi mysqldump ile veritabanı yedekleme yazısındaki yaklaşımla eşleştirin.

Son Çare: Her Şeyi Sıfırlamak#

Replikasyon yok, PITR ihtiyacı yok ve disk tamamen dolu olduğu için sunucu hiçbir şey yazamıyorsa, tüm binlog geçmişini sıfırlayabilirsiniz. Bu komut GTID geçmişini de temizler ve mevcut tüm replikaları geçersiz kılar:

-- MySQL 8.4 ve sonrası
RESET BINARY LOGS AND GTIDS;

-- MySQL 8.0, 5.7 ve MariaDB
RESET MASTER;

Uyarı: bu komut, "acaba yarın lazım olur mu" denecek bir şey değildir. Replikasyonu olan bir sunucuda çalıştırırsanız tüm kopyaları baştan kurmanız gerekir.

Bir Daha Dolmasın: Otomatik Süre Sınırı Koymak#

Binlog'u elle temizlemek yangını söndürür ama sebebi ortadan kaldırmaz. Kalıcı çözüm, MySQL'in günlükleri kendi kendine emekliye ayırmasıdır. Değişken adı sürümden sürüme değiştiği için karışıklık yaşanan yer tam da burasıdır:

5.7'den yükseltilmiş sunucularda en sık görülen hata, yapılandırma dosyasında kalan expire_logs_days = 0 satırının yeni varsayılanı ezmesidir. MySQL 8.4'te ise aynı satır sunucunun hiç açılmamasına yol açar, çünkü değişken artık tanınmıyor.

Çalışan sunucuda anında etkili olacak şekilde ayarlayın, sonra kalıcı hâle getirin:

-- 7 gün sakla (yeniden başlatmayı beklemeden)
SET GLOBAL binlog_expire_logs_seconds = 604800;

# /etc/mysql/mysql.conf.d/mysqld.cnf veya /etc/my.cnf.d/server.cnf
[mysqld]
binlog_expire_logs_seconds = 604800
max_binlog_size            = 256M
binlog_row_image           = MINIMAL

max_binlog_size, tek bir dosyanın hangi boyutta kapanıp yenisinin açılacağını belirler; küçük tutmak temizliği daha ince taneli yapar. binlog_row_image=MINIMAL günlük hacmini ciddi biçimde düşürür ancak bazı çoğaltma ve veri yakalama (CDC) araçları tam satır görüntüsü bekler — replikanız veya bir CDC boru hattınız varsa bu değişikliği önce test ortamında deneyin.

Otomatik emeklilik, açılışta ve her günlük dönüşünde çalışır; yani ayarı yaptığınız an eski dosyaların hemen silinmesini beklemeyin. Hemen yer açmak istiyorsanız FLUSH BINARY LOGS ile bir dönüş tetikleyin.

ibdata1 Şişmiş: Neden Küçültemiyorum?#

Şimdi geri dönüşü olmayan tuzağa geldik. ibdata1, InnoDB'nin sistem tablo alanıdır. Bu dosya hiçbir koşulda kendiliğinden küçülmez. İçindeki verileri silseniz, tabloları DROP etseniz, OPTIMIZE TABLE çalıştırsanız bile dosya diskte aynı boyutta kalır; MySQL sadece içeride boş alan işaretler ve o alanı sonraki yazımlarda tekrar kullanır. Bu bir hata değil, tasarım tercihidir.

ibdata1 iki ana sebeple şişer:

1. innodb_file_per_table kapalı. Bu ayar kapalıyken bütün tabloların verisi tek bir devasa ibdata1 dosyasına yazılır. MySQL 5.6'dan beri varsayılan açıktır, ama eski sunuculardan taşınan yapılandırma dosyalarında hâlâ innodb_file_per_table = 0 satırına rastlanır.

SHOW VARIABLES LIKE 'innodb_file_per_table';

2. Uzun süre açık kalan bir işlem. Commit edilmemiş devasa bir işlem, geri alma (undo) kayıtlarının birikmesine yol açar. Özellikle MySQL 5.7'de bu kayıtlar sistem tablo alanında tutulduğu için ibdata1 saatler içinde onlarca gigabayt büyüyebilir.

-- Saatlerdir açık duran işlem var mı?
SELECT trx_id, trx_started, trx_state, trx_rows_modified
FROM information_schema.INNODB_TRX
ORDER BY trx_started;

-- Geçmiş listesi uzunluğu (History list length) çok büyükse temizlik yetişemiyor demektir
SHOW ENGINE INNODB STATUS\G

ibdata1'i Gerçekten Küçültmenin Tek Yolu#

Kısayol yoktur. Tek yöntem, veriyi dışarı alıp veri dizinini sıfırdan kurmaktır. Yeterli boş diskiniz ve planlı bir bakım penceresi olmadan bu işe girişmeyin:

1. innodb_file_per_table = 1 ayarını yapılandırmaya ekleyin.
2. Tüm veritabanlarının mantıksal yedeğini alın: mysqldump --all-databases --single-transaction --routines --events --triggers > /yedek/tum.sql
3. Yedeği başka bir diske kopyalayıp bütünlüğünü doğrulayın (dosya boyutu, son satırda Dump completed ifadesi).
4. MySQL'i durdurun.
5. ibdata1, ib_logfile* ve veritabanı dizinlerini kaldırın (kullanıcı tabloları mysql şeması dâhil sıfırdan oluşacaktır).
6. MySQL'i başlatın; boş bir veri dizini ile ayağa kalkacaktır.
7. Yedeği geri yükleyin.

Bu işlem sırasında en sık yapılan hata, 3. adımı atlayıp yedeğin gerçekten okunabilir olduğunu doğrulamamaktır. Yedeği doğrulamadan ibdata1 dosyasına dokunan bir yönetici, veritabanının tamamını kaybeder.

Tek tek tabloları sistem tablo alanından çıkarmak istiyorsanız (dosya hâlâ küçülmez ama yeni veri artık ayrı .ibd dosyalarına gider):

ALTER TABLE veritabani.tablo ENGINE=InnoDB;

En büyük tabloları bulmak için:

SELECT table_schema, table_name,
       ROUND((data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.TABLES
WHERE table_schema NOT IN ('information_schema','performance_schema','sys','mysql')
ORDER BY (data_length + index_length) DESC
LIMIT 15;

Tablo şişmesinin sorgu tarafındaki nedenleri ve indeks bakımı için MySQL performans optimizasyonu yazısı iyi bir devam noktasıdır.

ibtmp1 ve Geçici Tablo Alanı#

ibtmp1, InnoDB'nin geçici tablolar için ayırdığı alandır. Diskte 12 MB olarak doğar ama ağır bir GROUP BY, ORDER BY ya da devasa bir JOIN sırasında bellekte sığmayan geçici tablolar buraya taşar. Tek bir kötü raporlama sorgusu bu dosyayı 40 GB'a çıkarabilir.

Kritik davranış: sorgu bitince alan içeride serbest bırakılır ama dosya küçülmez. ibtmp1 yalnızca MySQL yeniden başlatıldığında sıfırlanır. Yani gece çalışan tek bir rapor, siz sunucuyu yeniden başlatana kadar diskinizi işgal etmeye devam eder.

Kalıcı önlem, dosyaya bir tavan koymaktır:

[mysqld]
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:4G

Bu satır, geçici alanın 4 GB'ı aşmasını engeller. Karşılığında sınırı zorlayan sorgu The table 'tmp' is full hatası alır — tek bir sorgunun sunucunun tamamını çökertmesine tercih edilebilir bir sonuç. Değişikliği uygulamak için MySQL'i yeniden başlatmanız gerekir; başlatma sırasında ibtmp1 zaten yeniden oluşturulacağı için aynı anda mevcut şişkinlik de kaybolur.

Sürekli tekrarlıyorsa asıl mesele sorgulardır: geçici tabloları diske düşüren sorguları SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables' sayacıyla takip edin ve yavaş sorgu günlüğünden hangi raporun sorumlu olduğunu bulun.

Undo Tablo Alanları ve Redo Günlüğü#

MySQL 8.0'da geri alma kayıtları undo_001 ve undo_002 adlı ayrı dosyalarda tutulur. Normalde innodb_undo_log_truncate varsayılan olarak açıktır ve dosyalar innodb_max_undo_log_size sınırını (varsayılan 1 GB) aştığında otomatik kısaltılır. Buna rağmen büyümeye devam ediyorlarsa sebep neredeyse her zaman aynıdır: saatlerdir açık duran, commit edilmemiş bir işlem MySQL'in eski sürümleri temizlemesini engelliyordur. Çözüm dosyayı silmek değil, o işlemi bulup sonlandırmaktır.

SELECT trx_id, trx_mysql_thread_id, trx_started, trx_query
FROM information_schema.INNODB_TRX
WHERE trx_started < NOW() - INTERVAL 1 HOUR;

-- Gerekiyorsa ilgili oturumu sonlandırın
KILL 184213;

Redo günlükleri (ib_logfile0/ib_logfile1, MySQL 8.0.30 sonrası #innodb_redo dizini) ise sabit boyutludur; büyümezler, yalnızca yapılandırmada ne kadar yer ayırdıysanız o kadar tutarlar. Diskin dolmasında suçlu değildirler ve asla silinmezler — silinen bir redo günlüğü, kurtarılmamış işlemlerin kaybolması demektir.

Sorgu Günlükleri: Kolay Kazanç#

Bazen suçlu InnoDB değil, unutulmuş bir hata ayıklama ayarıdır. general_log bir kez açılıp kapatılmayı unutulduysa, her sorgu diske yazılıyor demektir; birkaç günde onlarca gigabayt üretebilir. Yavaş sorgu günlüğü de long_query_time yanlışlıkla 0'a çekilmişse aynı işi yapar.

SHOW VARIABLES LIKE 'general_log%';
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';

SET GLOBAL general_log = 'OFF';

Günlük dosyasını boşaltırken yine rm kullanmayın; süreç dosyayı açık tuttuğu için alan geri gelmez. Kapatın, içeriği sıfırlayın, gerekiyorsa tekrar açın:

mysql -e "SET GLOBAL general_log = 'OFF';"
: > /var/lib/mysql/sunucu.log
mysql -e "FLUSH LOGS;"

Bu dosyaların uzun vadeli yönetimi için logrotate ile log yönetimi yazısındaki döndürme kurallarını MySQL günlüklerine de uygulayabilirsiniz.

Disk %100 ve MySQL Hiç Açılmıyorsa#

En kötü senaryo: MySQL açılmadığı için PURGE komutunu çalıştıracak bir bağlantı bile kuramıyorsunuz. Sıralama şu:

1. Önce MySQL dışından yer açın. /var/log altındaki eski günlükleri sıkıştırın, journalctl --vacuum-size=200M çalıştırın, /tmp ve eski yedekleri temizleyin. Birkaç yüz megabayt bile MySQL'in ayağa kalkmasına yeter.
2. Ayağa kalkarsa normal yoldan PURGE BINARY LOGS çalıştırın. Bu, tercih edilen çözümdür.
3. Hâlâ kalkmıyorsa ve replikasyon ile PITR ihtiyacınız yoksa en eski binlog dosyalarını elle silebilirsiniz — ama tek başına değil: sildiğiniz her dosyanın satırını binlog.index içinden de çıkarmalısınız.

systemctl stop mysql
cd /var/lib/mysql

# En eski birkaç günlüğü sil
rm binlog.000301 binlog.000302 binlog.000303

# İndeks dosyasından da ilgili satırları çıkar
grep -v -e 'binlog.000301' -e 'binlog.000302' -e 'binlog.000303' \
  binlog.index > binlog.index.yeni
mv binlog.index.yeni binlog.index
chown mysql:mysql binlog.index

systemctl start mysql

Bu yöntem gerçekten son çaredir. binlog.index dosyasının sahipliğini mysql kullanıcısına geri vermeyi unutmayın; aksi hâlde sunucu yine açılmaz.

Sıkça Sorulan Sorular#

binlog dosyalarını rm ile silersem ne olur?#

Diskte yer açılır ama MySQL'in binlog.index dosyası hâlâ o dosyaları listeler. Sunucu bir sonraki temizlik veya yeniden başlatma sırasında bulunmayan dosyayı açmaya çalışır, hata günlüğüne yazar ve otomatik günlük temizleme mekanizması çalışmaz hâle gelir. Replikasyon varsa kopya sunucu okuyacağı dosyayı bulamayacağı için replikasyon kalıcı olarak durur ve replikayı sıfırdan kurmanız gerekir.

ibdata1 dosyasını silmek güvenli mi?#

Kesinlikle hayır. ibdata1, InnoDB'nin sistem tablo alanıdır; veri sözlüğü bilgileri, değişiklik tamponu ve bazı sürümlerde geri alma kayıtları burada tutulur. Silerseniz veritabanı bir daha açılmaz ve tablolarınız kurtarılamaz. Dosyayı küçültmenin tek yolu tüm veritabanlarının mantıksal yedeğini alıp veri dizinini sıfırdan oluşturmak ve yedeği geri yüklemektir.

Binlog'u tamamen kapatabilir miyim?#

Teknik olarak skip_log_bin ile kapatabilirsiniz, ancak bunu yalnızca replikasyonu ve zaman noktasına dönüş ihtiyacı olmayan tek sunuculu, yedeği başka yöntemle alınan sistemlerde düşünün. Binlog kapalıyken bir tabloyu yanlışlıkla silerseniz son yedeğin alındığı ana kadar geri dönebilirsiniz, aradaki tüm veri kaybolur. Çoğu durumda doğru cevap kapatmak değil, binlog_expire_logs_seconds ile makul bir saklama süresi belirlemektir.

PURGE çalıştırdım ama disk hâlâ dolu görünüyor, neden?#

İki olası sebep var. Birincisi, MySQL o an bağlı bir replikanın okuduğu dosyaları silmeyi reddeder; SHOW REPLICA STATUS çıktısındaki dosya adından öncesini temizleyebilirsiniz. İkincisi, bir süreç silinmiş dosyaları hâlâ açık tutuyordur — lsof -nP +L1 ile kontrol edin. Ayrıca sildiğiniz alanın başka bir bölümde olup olmadığını df -h ile doğrulayın.

expire_logs_days ayarını yaptım ama eski günlükler silinmiyor?#

MySQL 8.0 ve sonrasında bu değişkenin yerini binlog_expire_logs_seconds aldı; MySQL 8.4'te ise tamamen kaldırıldı ve yapılandırmada bırakılırsa sunucu açılmaz. Ayrıca süre dolmuş günlüklerin temizliği anlık değildir: yalnızca sunucu açılışında ve her günlük dönüşünde tetiklenir. Hemen etkisini görmek için FLUSH BINARY LOGS komutuyla bir dönüş başlatabilirsiniz.

ibtmp1 dosyası neden yeniden başlatmadan küçülmüyor?#

ibtmp1 geçici tablo alanıdır ve InnoDB, içindeki alanı sorgu bittiğinde mantıksal olarak serbest bırakır ama dosyayı diskte kısaltmaz — sonraki sorgular aynı alanı tekrar kullanır. Dosyanın fiziksel boyutu yalnızca MySQL yeniden başlatıldığında sıfırlanır. Tekrarı önlemek için innodb_temp_data_file_path ayarına max:4G gibi bir tavan koyun ve geçici tabloları diske düşüren ağır sorguları yavaş sorgu günlüğünden bulup düzeltin.