Merhaba arkadaşlar, bugün sizlere özellikle yoğun veritabanı kullanan sunucularınızda kritik bir konudan bahsedeceğim: Veritabanı ve tablo boyutlarınızı nasıl kontrol eder, büyüme eğilimini nasıl izlersiniz? Bu işlem, disk alanı planlaması yapmanızı, performans darboğazlarını önceden görmenizi ve gereksiz büyümeyi (örneğin log tablolarında) tespit ederek temizlik yapmanızı sağlar. Benim sunucularda düzenli olarak yaptığım bir kontrol rutinidir.
Veritabanı Boyutlarını Sorgulama
İlk olarak, sunucunuzdaki tüm veritabanlarının toplam boyutunu ve her birinin ayrı ayrı ne kadar yer kapladığını görelim. Aşağıdaki SQL sorgusu bu iş için birebirdir. MySQL veya MariaDB komut satırına bağlanıp çalıştırabilirsiniz.
Bu sorgu, veritabanlarını toplam boyuta göre büyükten küçüğe sıralayacak. Hangi veritabanının en çok yeri kapladığını hemen görebilirsiniz. İndeks boyutuna da dikkat edin, beklenmedik şekilde büyük olabilir.
Belirli Bir Veritabanındaki Tablo Boyutlarını İnceleme
"forum_db" gibi büyük görünen bir veritabanınız varsa, içindeki hangi tabloların bu boyuta neden olduğunu detaylı incelemelisiniz. Şu ayara çok dikkat etmelisiniz: Büyük tablolar, sorgu performansını doğrudan etkiler.
Bu sorgu, belirttiğiniz veritabanındaki tüm tabloları büyükten küçüğe listeler. Genellikle post, session, search_log gibi tablolar zamanla çok büyüyebilir. Satır sayısı yaklaşık değerdir, InnoDB motoru için tam doğru olmayabilir ama fikir verir.
Büyüme Eğilimini İzleme ve Otomasyon
Boyutları bir kere kontrol etmek yetmez, zaman içindeki büyüme hızını (trend) izlemek çok daha önemlidir. Bunun için basit bir shell scripti yazıp cron job olarak planlayabilirsiniz. Script, boyut bilgilerini düzenli olarak bir log dosyasına yazsın.
Aşağıdaki bash scriptini, örneğin /usr/local/bin/check_db_size.sh dosyası olarak kaydedin ve çalıştırma izni verin (
).
Daha sonra,
komutu ile cron'a ekleyin. Her gün gece 03:00'te çalıştırmak için:
Bu sayede /var/log/db_size_history.log dosyasını düzenli olarak kontrol ederek hangi veritabanının ne kadar büyüdüğünü görebilirsiniz. Log dosyasını
komutu ile takip edebilirsiniz.
Dikkat Edilmesi Gerekenler ve Optimizasyon İpuçları
information_schema.tables sorguları çok ağır tablolarda hafif bir performans etkisi yapabilir. Bu nedenle bu kontrolleri yoğun saatler dışında yapın.
Bir tablo aşırı büyüdüyse (örneğin 10 GB üzeri), sadece DELETE ile satır silmek yeterli olmaz. Disk alanını geri kazanmak ve performans için tabloyu optimize etmeniz (OPTIMIZE TABLE tablo_adi;) veya partition kullanmanız gerekebilir. Ancak OPTIMIZE TABLE işlemi tabloyu kilitleyebilir, bakım penceresinde yapın.
Büyüyen tablolarınız için bir "veri saklama politikası" (retention policy) belirleyin. Örneğin, 6 aydan eski oturum (session) kayıtlarını silen bir cron job kurabilirsiniz.
Scriptte kullandığınız kullanıcının (monitor_user) sadece SELECT yetkisi olmalı, kesinlikle tam yetkili root kullanıcısını script içinde kullanmayın.
Sonuç
Veritabanı boyutlarını düzenli izlemek, proaktif sistem yönetiminin temel taşlarından biridir. Ani disk dolması yaşamadan, performans düşüşlerini öngörerek müdahale etmenizi sağlar. Ben genelde haftalık bir rapor alıp, aylık bazda büyüme trendine bakarım.
Peki siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Veritabanı boyut takibi için farklı yöntemler veya favori araçlarınız var mı? (örneğin phpMyAdmin, Percona Monitoring and Management). Sorusu olan veya eklemek istediği bir ipucu olan aşağıya yazsın, beraber tartışalım.
Veritabanı Boyutlarını Sorgulamaİlk olarak, sunucunuzdaki tüm veritabanlarının toplam boyutunu ve her birinin ayrı ayrı ne kadar yer kapladığını görelim. Aşağıdaki SQL sorgusu bu iş için birebirdir. MySQL veya MariaDB komut satırına bağlanıp çalıştırabilirsiniz.
SQL:
SELECT
table_schema AS `Veritabanı Adı`,
ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS `Toplam Boyut (MB)`,
ROUND(SUM(data_length) / 1024 / 1024, 2) AS `Veri Boyutu (MB)`,
ROUND(SUM(index_length) / 1024 / 1024, 2) AS `İndeks Boyutu (MB)`
FROM information_schema.tables
GROUP BY table_schema
ORDER BY `Toplam Boyut (MB)` DESC;Bu sorgu, veritabanlarını toplam boyuta göre büyükten küçüğe sıralayacak. Hangi veritabanının en çok yeri kapladığını hemen görebilirsiniz. İndeks boyutuna da dikkat edin, beklenmedik şekilde büyük olabilir.
Belirli Bir Veritabanındaki Tablo Boyutlarını İnceleme"forum_db" gibi büyük görünen bir veritabanınız varsa, içindeki hangi tabloların bu boyuta neden olduğunu detaylı incelemelisiniz. Şu ayara çok dikkat etmelisiniz: Büyük tablolar, sorgu performansını doğrudan etkiler.
SQL:
SELECT
table_name AS `Tablo Adı`,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS `Toplam Boyut (MB)`,
ROUND((data_length) / 1024 / 1024, 2) AS `Veri Boyutu (MB)`,
ROUND((index_length) / 1024 / 1024, 2) AS `İndeks Boyutu (MB)`,
table_rows AS `Satır Sayısı (Yaklaşık)`
FROM information_schema.tables
WHERE table_schema = 'forum_db' -- Burayı kontrol etmek istediğiniz veritabanı adıyla değiştirin
ORDER BY (data_length + index_length) DESC;Bu sorgu, belirttiğiniz veritabanındaki tüm tabloları büyükten küçüğe listeler. Genellikle post, session, search_log gibi tablolar zamanla çok büyüyebilir. Satır sayısı yaklaşık değerdir, InnoDB motoru için tam doğru olmayabilir ama fikir verir.
Büyüme Eğilimini İzleme ve OtomasyonBoyutları bir kere kontrol etmek yetmez, zaman içindeki büyüme hızını (trend) izlemek çok daha önemlidir. Bunun için basit bir shell scripti yazıp cron job olarak planlayabilirsiniz. Script, boyut bilgilerini düzenli olarak bir log dosyasına yazsın.
Aşağıdaki bash scriptini, örneğin /usr/local/bin/check_db_size.sh dosyası olarak kaydedin ve çalıştırma izni verin (
Bash:
chmod +x /usr/local/bin/check_db_size.sh
Bash:
#!/bin/bash
# Log dosyasının yolu
LOG_FILE="/var/log/db_size_history.log"
# MySQL/MariaDB bağlantı bilgileri (güvenlik için bu bilgileri ayrı bir .my.cnf dosyasında tutmak daha iyidir)
MYSQL_USER="monitor_user"
MYSQL_PASS="guclu_bir_sifre"
MYSQL_HOST="localhost"
# Tarih damgası ekle
echo "=== $(date '+%Y-%m-%d %H:%M:%S') ===" >> $LOG_FILE
# Toplam veritabanı boyutunu logla
mysql -h$MYSQL_HOST -u$MYSQL_USER -p$MYSQL_PASS --skip-column-names <<EOF >> $LOG_FILE
SELECT CONCAT(table_schema, ' -> ', ROUND(SUM(data_length + index_length) / 1024 / 1024, 2), ' MB')
FROM information_schema.tables
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;
EOF
echo "" >> $LOG_FILE # Boş satır bırakDaha sonra,
Bash:
crontab -e
Bash:
0 3 /usr/local/bin/check_db_size.shBu sayede /var/log/db_size_history.log dosyasını düzenli olarak kontrol ederek hangi veritabanının ne kadar büyüdüğünü görebilirsiniz. Log dosyasını
Bash:
tail -f /var/log/db_size_history.loginformation_schema.tables sorguları çok ağır tablolarda hafif bir performans etkisi yapabilir. Bu nedenle bu kontrolleri yoğun saatler dışında yapın.
Bir tablo aşırı büyüdüyse (örneğin 10 GB üzeri), sadece DELETE ile satır silmek yeterli olmaz. Disk alanını geri kazanmak ve performans için tabloyu optimize etmeniz (OPTIMIZE TABLE tablo_adi;) veya partition kullanmanız gerekebilir. Ancak OPTIMIZE TABLE işlemi tabloyu kilitleyebilir, bakım penceresinde yapın.
Büyüyen tablolarınız için bir "veri saklama politikası" (retention policy) belirleyin. Örneğin, 6 aydan eski oturum (session) kayıtlarını silen bir cron job kurabilirsiniz.
Scriptte kullandığınız kullanıcının (monitor_user) sadece SELECT yetkisi olmalı, kesinlikle tam yetkili root kullanıcısını script içinde kullanmayın.
SonuçVeritabanı boyutlarını düzenli izlemek, proaktif sistem yönetiminin temel taşlarından biridir. Ani disk dolması yaşamadan, performans düşüşlerini öngörerek müdahale etmenizi sağlar. Ben genelde haftalık bir rapor alıp, aylık bazda büyüme trendine bakarım.
Peki siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Veritabanı boyut takibi için farklı yöntemler veya favori araçlarınız var mı? (örneğin phpMyAdmin, Percona Monitoring and Management). Sorusu olan veya eklemek istediği bir ipucu olan aşağıya yazsın, beraber tartışalım.