Sunucu yönetimi

MySQL ve MariaDB bakımı: yedek, ayar ve yavaş sorgular

Veritabanı çoğu web uygulamasında ilk sıkışan bileşendir. Yedek, ayar, yavaş sorgu avı ve erişim güvenliği üzerine pratik bakım rehberi.

8 dakika okuma
Veri yollarıyla bağlı veritabanı katmanları ve bakım aracı

Veritabanı, çoğu web uygulamasında ilk sıkışan bileşendir. İyi haber şu: en büyük kazançlar birkaç basit bakım alışkanlığından gelir.

Tutarlı yedek almak

Veritabanı dosyalarını kopyalamak yedek değildir — çalışan bir veritabanının dosyaları her an tutarsız olabilir. Döküm alın:

bashmysqldump -u root -p --single-transaction --routines --triggers --databases uygulama | gzip > uygulama-$(date +%F).sql.gz

--single-transaction parametresi InnoDB tablolarında kilit almadan tutarlı bir anlık görüntü alır; site çalışmaya devam eder. --routines ve --triggers olmadan saklı yordamlarınız ve tetikleyicileriniz yedeğe girmez — bu, geri yükleme sırasında fark edilen yaygın bir eksiktir.

Geri yükleme:

bashgunzip < uygulama-2026-09-22.sql.gz | mysql -u root -p

Geri yüklemeyi düzenli olarak deneyin. Test edilmemiş yedek, yedek değildir; ayrıntılar yedekleme rehberimizde.

Yavaş sorguları bulmak

Yavaşlığın sebebini tahmin etmek yerine ölçün. Yavaş sorgu günlüğünü açın:

text[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Bir saniyeden uzun süren her sorgu kaydedilir. Birikenleri özetlemek için:

bashmysqldumpslow -s t /var/log/mysql/slow.log | head -20

Şüpheli bir sorguyu incelemek için başına EXPLAIN ekleyin:

textEXPLAIN SELECT * FROM siparisler WHERE musteri_id = 42;

Çıktıdaki type sütununda ALL görüyorsanız tam tablo taraması yapılıyor demektir; rows sütunu da taranan satır sayısını verir. Çözüm genellikle bir indekstir:

textCREATE INDEX idx_siparisler_musteri ON siparisler (musteri_id);

İndeks sihirli değnek değildir: her indeks yazma işlemlerini biraz yavaşlatır ve disk yer kaplar. Yalnızca gerçekten sorgulanan sütunlara ekleyin.

Bellek ayarı: tek önemli parametre

Onlarca ayar arasında InnoDB tampon havuzu diğerlerinin toplamından daha çok fark yaratır. Veritabanının sık okunan verisi buraya sığdığında diske gidilmez.

text[mysqld]
innodb_buffer_pool_size = 2G

Kaba kural: adanmış bir veritabanı sunucusunda toplam belleğin %50-70'i. Ama web sunucusu ve PHP aynı makinedeyse bu kadarını ayıramazsınız — o durumda %25 civarı daha güvenlidir. Fazlasını vermek, sistemin takas alanına düşmesine yol açar ki bu her şeyi yavaşlatır.

Mevcut değeri görmek için:

bashmysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Değişiklikten sonra servisi yeniden başlatın.

Uzaktan erişimi kapatın

Bu, veritabanı sunucularında en sık yapılan güvenlik hatasıdır. Varsayılan olarak yalnızca yerelden dinlemesi gerekir:

text[mysqld]
bind-address = 127.0.0.1

Kontrol edin:

bashss -lptn | grep 3306

Çıktıda 0.0.0.0:3306 görüyorsanız veritabanınız internete açıktır. 3306 portunu güvenlik duvarından asla dışarıya açmayın. Uzaktan bağlanmanız gerekiyorsa SSH tüneli kullanın:

bashssh -L 3306:127.0.0.1:3306 kullanici@sunucu-ip

Artık kendi bilgisayarınızdan 127.0.0.1:3306 adresine bağlanabilirsiniz; trafik SSH üzerinden şifreli gider.

Düzenli temizlik

Uygulama seviyesinde biriken veri zamanla sorguları yavaşlatır:

  • Oturum ve önbellek tabloları — süresi dolmuş kayıtları düzenli silin
  • Günlük ve denetim tabloları — saklama süresi belirleyin, eskisini arşivleyin
  • WordPress kullanıyorsanız yazı revizyonları ve autoload işaretli seçenekler; ayrıntısı WordPress hızlandırma rehberimizde

Tablo boyutlarını görmek için:

textSELECT table_name, ROUND((data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.tables
WHERE table_schema = 'uygulama'
ORDER BY mb DESC LIMIT 10;

Veritabanı sunucunuzun kaynak planlamasını birlikte gözden geçirmek isterseniz bize yazın.