Veritabanı Fiziksel Sunucusu İçin Güvenli Yapılandırma Rehberi

Veritabanı fiziksel sunucusu, veritabanı iş yükünü tek bir donanım üzerinde toplarken gecikmeyi, kapasiteyi ve geri dönüş riskini daha öngörülebilir hale getirmek için seçilir; doğru kurulumda CPU, RAM ve disk katmanı birlikte dengelenir. En güvenli başlangıç yaklaşımı, önce mevcut darboğazı ayırmak, sonra yalnız ilgili katmanı değiştirmek ve sonucu metriklerle doğrulamaktır. Bellek baskısı, swap hareketi, disk gecikmesi ve yavaş sorgu davranışı birlikte okunmadan yapılan ayar değişiklikleri çoğu zaman yanlış hedefe müdahale eder. Bu rehber, fiziksel sunucuda veritabanı çalıştırırken hangi donanım tercihinin neyi etkilediğini, hangi ayarın güvenli başlangıç sayılacağını, değişikliğin nasıl test edileceğini ve gerektiğinde geri nasıl alınacağını pratik bir çerçevede anlatır. Kapsam, canlı üretimden önce ölçüm yapabilen ve yedek planı olan ekipler içindir; kesin sayı vermek yerine ortamınıza göre karar vermeyi öğretir.

Bu sunucu tipi ne zaman doğru seçim olur?

Veri yerelde kalacaksa, disk gecikmesi iş sonucunu doğrudan etkiliyorsa ve aynı makinede başka ağır servisler çalışmaması isteniyorsa fiziksel sunucu anlamlıdır. Özellikle tek bir veritabanı motorunun kritik yükünü taşıyan yapılarda, donanımı önceden bilmek kapasite planlamasını kolaylaştırır. Buna karşılık trafik dalgalanması çok yüksek, kısa ömürlü test ortamı veya sık dikey esneklik gerektiren kurulumlarda fiziksel sunucu her zaman en pratik seçenek olmayabilir. Bu ayrımı baştan yapmak, daha sonra gereksiz maliyet veya bakım yükü taşımayı önler.

• Uygun olduğu durum: Sabit yük, düşük gecikme hedefi ve yerel depolama ihtiyacı.
• Daha dikkatli olunması gereken durum: Sık ölçek değiştiren, çok kiracılı veya kısa ömürlü test ortamları.
• Karar ölçütü: Darboğazın CPU mu, RAM mi, disk mi olduğunu net ölçebiliyor musunuz?

Mevcut durumu okumak: darboğazı yanlış yerde aramayın

İlk adım, performans sorununu hangi katmanın ürettiğini ayırmaktır. Düşük gecikme beklenen bir veritabanında yüksek iowait varsa sorun çoğunlukla disk tarafındadır; CPU kullanımı yüksek ama disk beklemesi düşükse işlemci sınırına yaklaşmış olabilirsiniz; swap hareketi ve sık sayfa dışına çıkma görülüyorsa önce belleği kontrol etmek gerekir. Bu ayrımı yapmadan RAM eklemek, disk değiştirmek veya çekirdek ayarı oynamak çoğu zaman yanlış hedefe müdahale etmektir.

free -h
lsblk -o NAME,SIZE,ROTA,TYPE,MOUNTPOINT
iostat -xz 1
vmstat 1

Beklenen okuma: free -h çıktısında kullanılabilir bellek tamamen tükenmemeli, iostat -xz 1 ile disk üzerinde uzun süreli yüksek await ve düşük boşluk görülmemeli, vmstat 1 içinde düzenli swap in/out hareketi olmamalıdır. Servis adını izlemeniz gerekiyorsa dağıtıma göre değişebileceğini unutmayın; veritabanı servisini bulmak için systemctl list-units --type=service | grep -Ei 'mysql|maria|postgres|mongod|redis|opensearch' komutu ile gerçek adı doğrulamak daha güvenlidir.

Veritabanı fiziksel sunucusu için güvenli başlangıç değerleri

Tek doğru sayı yoktur; yine de başlangıçta hedeflenen profil, sistemi güvenli tarafta tutar. Küçük ama kritik bir veritabanı için işlemci çekirdeğini değil önce diski ve belleği rahatlatmak gerekir. Orta yoğunlukta bir üretim ortamında NVMe tabanlı yerel depolama, yeterli ECC bellek ve ayrı yedek alanı çoğu zaman ham çekirdek sayısından daha fazla fark yaratır. Yük büyüdükçe okuma önbelleği, yazma günlüğü ve yedek akışı birbirinden ayrılmalıdır.

Bellek ayarı neyi değiştirir?

Bellek, çoğu veritabanı için ilk denge noktasıdır. İlişkisel motorlarda önbellek büyüdükçe sık kullanılan sayfalar disk yerine RAM’den okunur; bu da gecikmeyi azaltır. Ancak tüm belleği veritabanına bırakmak doğru değildir; işletim sistemi, log yazımı, ağ tamponları ve yönetim araçları için boşluk kalmalıdır. Güvenli başlangıç yaklaşımı, üretim verisini taşımaya yetecek ama sisteme nefes aldıracak bir tampon bırakmaktır. Eğer düzenli swap görülüyorsa önce iş setini küçültmeden ya da RAM artırmadan agresif bellek ayarı yapmak çoğu zaman yanlış yön olur.

Disk yerleşimi neden kritik?

Veritabanında en pahalı gecikme, saniyede çok işlem yapan ama yazmada bekleyen disktir. Veri dosyası, günlük dosyası, geçici alan ve yedek hedefi aynı fiziksel diskte birleştiğinde yazma patlaması sırasında bütün sistem yavaşlar. Mümkünse üretim veri yolu ile yedek yolu ayrılmalı, yazma yoğun günlük dosyaları ayrı bir katmanda tutulmalı ve disk doluluk oranı düzenli izlenmelidir. RAID yapılandırması her zaman zorunlu değildir, fakat tek nokta arızası kabul edilemezse yansıtma veya eşdeğer dayanıklılık düşünülmelidir.

CPU ne zaman ikinci planda kalır?

Sorgu süresi uzuyorsa ama CPU düşük, iowait yüksekse işlemciyi büyütmek çoğu zaman fayda sağlamaz. CPU, karmaşık birleştirmeler, sıkıştırma, indeksleme ve çok oturumlu yürütmede önemlidir; buna rağmen çoğu fiziksel veritabanı probleminde ilk sınır disk gecikmesi veya bellek baskısı olur. İşlemciyi sonradan artırmak mantıksız değildir, fakat ölçüm sonucu bunu desteklemiyorsa bütçeyi önce daha hızlı depolamaya ya da daha geniş belleğe ayırmak daha akıllıcadır.

Motorlara göre baskın kaynak değişir

İlişkisel motorlarda disk ve cache dengesi öne çıkarken, bellek içi çalışan sistemlerde RAM kapasitesi ve veri sığdırma oranı daha belirleyici olabilir. Arama odaklı motorlarda da disk düzeni ve bellek eşlemesi, sorgu gecikmesi üzerinde doğrudan etkilidir. Bu yüzden aynı fiziksel sunucu profili her motor için eşit derecede iyi çalışmaz; motorun yazma modeli, indeks yapısı ve kurtarma davranışı mutlaka dikkate alınmalıdır.

Uygulama düzeyinde ilk ayar paketi nasıl seçilir?

İşletim sistemi tarafında amaç, veritabanının kaynak tüketimini kontrol altında tutmaktır. Gereksiz arka plan servislerini azaltmak, güncelleme pencerelerini üretim saatlerinden uzak tutmak ve sayfa değişimini sınırlamak temel yaklaşımdır. Veritabanı tarafında ise bellek önbelleği, yazma günlüğü ve checkpoint sıklığı gibi ayarlar dikkatle ele alınmalıdır. Burada güvenli başlangıç, agresif değil dengeli bir profil demektir; hızlı başlamak değil, ölçerek yükseltmek gerekir.

• İşletim sistemi: Disk doluluk eşiği, swap baskısı ve çekirdek logları izlenmeli.
• Veritabanı önbelleği: İş setinin önemli kısmını tutacak kadar büyük olmalı, ama OS belleğini boğmamalı.
• Yazma davranışı: Log ve veri akışı mümkün olduğunca tahmin edilebilir tutulmalı.
• Yedekleme: Canlı yükün en yoğun olduğu saatlere bindirilmemeli.

Eğer ayar değiştiriyorsanız, her kritik değer için şunu yazılı hale getirin: mevcut değer, önerilen başlangıç değeri, beklenen etki ve yanlış değer riski. Bu dört bilgi olmadan yapılan değişiklik, sonradan neden-sonuç zincirini takip etmeyi zorlaştırır.

Doğrulama: değişiklik gerçekten işe yaradı mı?

Başarı ölçütü sadece daha yüksek bir benchmark sonucu değildir. Uygulama yanıt süresinin daralması, yavaş sorgu sayısının düşmesi, disk gecikmesinin sınırlanması ve swap hareketinin durması birlikte değerlendirilmelidir. En iyi test, gerçek iş yüküne yakın bir örnek trafik altında alınan ölçümdür. Sırf boş sistemde iyi görünen ayar, üretimde aynı sonucu vermeyebilir.

1. Değişiklikten önce temel metrikleri kaydedin: CPU, RAM, disk gecikmesi, bağlantı sayısı ve yavaş sorgu örnekleri.
2. Tek bir ayar grubunu değiştirin; bellek, disk ve işlemciyi aynı anda değiştirmeyin.
3. Aynı zaman aralığında tekrar ölçün ve önceki değerle karşılaştırın.
4. Loglarda beklenmeyen hata, recovery döngüsü veya yüksek gecikme uyarısı olup olmadığını kontrol edin.
5. Uygulama tarafında kullanıcıya yansıyan yanıt süresi iyileşmesini doğrulayın.

Burada kritik nokta, testin sadece teknik metriğe değil, uygulamanın davranışına da bakmasıdır. Sorgu daha hızlı çalışıyorsa ama başka bir yerde hatalı kilitleme veya artan bellek tüketimi oluşuyorsa ayar tam doğru kabul edilmemelidir.

Geri alma ve güvenli dönüş planı

Canlı sistemde yapılan her değişikliğin geri alınabilir olması gerekir. Önce yedek alın, sonra yalnız bir katmanda değişiklik yapın ve eski ayarı saklayın. Eğer dosya sistemi, disk yerleşimi veya veritabanı önbelleği değiştiyse, dönüş sırasında önce uygulama erişimini durdurup sonra eski ayara dönmek daha güvenlidir. Özellikle veri dosyası ile günlük dosyasının yerini değiştirdiyseniz, eski mount noktasının ve izinlerin geri geldiğini test etmeden üretime çıkmayın.

• DB konfigürasyonunun bir kopyasını ayrı yerde saklayın.
• OS seviyesindeki tunable ayarları tek tek geri alın.
• Disk değiştiyse, eski performans ve mount durumunu doğrulayın.
• Geri dönüşten sonra aynı doğrulama metriklerini yeniden ölçün.

En sık yapılan hatalar

• Ham donanımı performans sanmak: Güçlü CPU, yavaş diski telafi etmez.
• Belleği sonuna kadar doldurmak: İşletim sistemine pay bırakılmadığında swap baskısı artar.
• Veri, log ve yedek akışını aynı diske yığmak: Yazma zirveleri tüm sistemi etkiler.
• Tek metrikle karar vermek: Sadece CPU’ya bakıp disk gecikmesini gözden kaçırmak yaygındır.
• Rollback planı olmadan canlı ayar değiştirmek: Geri dönüş yolu yoksa küçük sorun büyük kesintiye döner.

Uygulamadan önce son kontrol

• İş yükünün okuma-yazma oranı ve veri boyutu net mi?
• CPU, RAM ve disk için başlangıç profili ölçüme dayanıyor mu?
• Yedekleme hedefi ve geri dönüş yolu hazır mı?
• Değişiklik tek tek ve test edilerek uygulanacak mı?
• Başarı ölçütü sadece hız değil, log ve uygulama davranışıyla birlikte mi değerlendirilecek?

Bu çerçeve, veritabanı fiziksel sunucusu kurulumunu rastgele bir kapasite alımından çıkarıp ölçülebilir bir yapılandırma sürecine dönüştürür. En güvenli yaklaşım, önce darboğazı ayırmak, sonra yalnız ilgili katmanı değiştirmek ve her adımı aynı metriklerle doğrulamaktır.