SQL Fiziksel Sunucu Kiralama Rehberi: Seçim, Kurulum ve İlk Testler

SQL Fiziksel Sunucu Kiralama, veritabanı iş yükünü paylaşımlı altyapıdan ayırıp disk gecikmesini, komşu trafik etkisini ve yönetim belirsizliğini azaltmak isteyen ekipler için doğru seçenek olabilir. Bu model, özellikle yoğun yazma yapan uygulamalarda, büyük indekslerde, sık raporlama sorgularında ve düşük gecikme beklentisi olan sistemlerde daha öngörülebilir davranış sağlar. Ancak karar yalnızca daha fazla kaynak almak değildir; iş yükünün okuma-yazma oranı, eşzamanlı bağlantı sayısı, veri boyutu, yedekleme penceresi ve uzaktan erişim modeli birlikte değerlendirilmelidir. Fiziksel sunucu doğru seçilmezse maliyet artar ama gecikme düşmez; yanlış ağ veya disk düzeni varsa uygulama tarafı yine tıkanır. Bu yüzden kiralama sürecini, sunucuyu teslim almak, işletim sistemini hazırlamak, veritabanı servislerini açmak, erişimi sınırlandırmak ve yük testini çalıştırmak şeklinde düşünmek gerekir. Aşağıdaki akış, SQL veritabanı için fiziksel sunucu seçerken neye bakacağınızı ve ilk gün hangi kontrolleri yapacağınızı somutlaştırır.

SQL Fiziksel Sunucu Kiralama hangi durumda mantıklı olur?

Bu model en çok, veritabanının tek başına belirgin kaynak tükettiği senaryolarda anlamlıdır. Örneğin yoğun yazma yapan uygulamalar, büyük indeksler, sık raporlama sorguları, gecikmeye hassas işlem akışları ve uygulama katmanından bağımsız tutulması gereken veriler fiziksel sunucuda daha rahat yönetilir. Aynı makinede çok sayıda servis çalışıyorsa, veritabanı ile diğer servislerin RAM ve disk rekabeti sorun çıkarabilir; fiziksel sunucu bu rekabeti azaltır.

Öte yandan, veri boyutu küçükse, trafik düşükse ve operasyon ekibiniz sunucu bakımıyla uğraşmak istemiyorsa, fiziksel sunucu gereksiz karmaşıklık yaratabilir. Bu yüzden karar sadece performans değil, bakım sorumluluğu ve yedekleme disiplini açısından da verilmelidir.

• Uygun olduğu durumlar: yüksek yazma yükü, düşük gecikme ihtiyacı, veri izolasyonu, özel güvenlik sınırları.
• Daha az uygun olduğu durumlar: küçük test verileri, kısa ömürlü projeler, bakım için sınırlı teknik kaynak.

Kiralama öncesi iş yükü kontrolü

İlk adım, veritabanının bugün ne kadar kaynak kullandığını ve büyümenin nasıl ilerlediğini görmektir. Gece çalışan raporlar, yoğun saatlerdeki bağlantı sayısı, günlük veri artışı, yedekleme süresi ve geri yükleme süresi bu kararı etkiler. Sunucuyu kiralamadan önce bir staging ortamında veya mevcut sistem üzerinde kısa bir performans ölçümü yapmak, yanlış donanım seçimini erken yakalar.

• Veri seti büyüklüğünü ve aylık artışı çıkarın.
• Okuma ve yazma oranını ayırın; her iş yükü aynı kaynakları tüketmez.
• Uygulamanın hangi saatlerde yoğunlaştığını not edin.
• Yedekleme penceresinin iş saatleriyle çakışmadığını kontrol edin.
• Uzak erişim gerekiyorsa hangi IP’lerin bağlanacağını baştan belirleyin.

Bu hazırlık, yalnız donanım değil erişim planını da netleştirir. Kiralanan fiziksel sunucuya dışarıdan herkesin bağlanabilmesi çoğu senaryoda yanlış varsayımdır; veritabanı portu yalnızca izinli adreslere açık olmalıdır.

SQL Fiziksel Sunucu Kiralama öncesi donanım kontrolü

Veritabanı için fiziksel sunucuda dört kaynak öne çıkar: disk, bellek, işlemci ve ağ. Bunların etkisi birbirini tamamlar; yalnız işlemciyi büyütmek çoğu zaman yeterli olmaz. Aşağıdaki tablo, seçim yaparken neyin neyi değiştirdiğini özetler.

Donanım tarafında özellikle veri diski ile günlük diskini aynı yerde tutmamak önemlidir. Yazma yoğun sistemlerde bu ayrım, bekleme süresini hissedilir biçimde azaltabilir. Ayrıca ECC bellek, diskte güç kaybına karşı koruma ve yedekli disk düzeni gibi ayrıntılar, sunucuyu ilk bakışta pahalı gösterse de operasyon riskini aşağı çeker.

İlk kurulumda güvenli sıra

1. Sunucuyu önce kapalı ağda hazırlayın. İşletim sistemi güncellemelerini tamamlayın, gereksiz servisleri kapatın ve yalnız ihtiyaç duyduğunuz yönetim erişimini açık bırakın.
2. Disk düzenini netleştirin. Veri, günlük ve yedek alanı için ayrı mantıksal ayrım kurun. Küçük sistemlerde bu ayrım tek diskte bölümleme olarak da yapılabilir, fakat ayrı fiziksel disk her zaman daha rahat çalışır.
3. Veritabanı servis adını doğrulayın. Dağıtıma göre servis adı mysql, mariadb veya postgresql olabilir. Önce gerçek adı görün, sonra status ya da restart komutunu ona göre kullanın.
4. Dinleme adresini sınırlandırın. Veritabanı dış dünyaya açık olmak zorunda değildir; uygulama sunucusunun IP’si veya özel ağ adresi çoğu zaman yeterlidir.
5. Yedekleme hedefini ilk günden ekleyin. Yerel disk tek başına yeterli sayılmaz; uzak depo veya başka bir sunucuya kopya planı olmadan kurulum tamamlanmış sayılmamalıdır.

systemctl list-units --type=service | grep -E 'mysql|mariadb|postgresql'

Bu komut, hangi veritabanı servisinin gerçekten kurulu olduğunu görmenize yardım eder. Ardından uygun servis adıyla durum kontrolü yapın; beklenen sonuç active (running) benzeri bir durumdur. Servis adı dağıtıma göre değişebileceği için körlemesine yeniden başlatma yapmayın.

SELECT 1;

Bu test sorgusu, bağlantının çalıştığını hızlıca doğrular. Sorgu döndüğünde amaç yalnızca sonuç almak değil, aynı zamanda bağlantının beklenenden uzun sürmemesini ve uygulama tarafındaki oturumların kopmamasını gözlemlemektir.

Ayarların performansa etkisi

Kurulumdan sonra asıl farkı yaratan şey, sunucu kaynağını nasıl kullandığınızdır. Aşağıdaki ayarlar ürün bağımsızdır; hangi veritabanını kullanırsanız kullanın, mantık aynıdır.

Bu ayarlarda güvenli başlangıç, önce kısıtlı açmak, test etmek ve sonra gerektiği kadar genişletmektir. Veritabanı tarafında “varsayılanla bırakmak” yerine her kapı, her ağ adresi ve her yedek hedefi tek tek doğrulanmalıdır.

Günlük işletim ritmi

Fiziksel sunucu kiralandıktan sonra iş, kurulumla bitmez. Günlük ritimde üç şeyin düzenli kontrol edilmesi gerekir: disk doluluk oranı, yedeklerin başarılı olup olmadığı ve servislerin beklenen durumda çalışıp çalışmadığı. Haftalık olarak bir geri yükleme testi yapmak, aylık olarak kapasiteyi tekrar değerlendirmek ve bakım penceresi içinde güncelleme planlamak sağlıklı bir alışkanlıktır.

• Disk kullanımını izleyin; loglar ve geçici dosyalar hızla büyüyebilir.
• Yedek başarılı görünse bile geri yükleme denemesi yapın.
• Bağlantı havuzu ve uygulama hata kayıtlarını takip edin.
• Güvenlik güncellemelerini bakım zamanına alın, anlık üretim saatine değil.

Bu aşamada amaç, sistemi “çalışıyor görünüyor” seviyesinde bırakmamak; veri kaybı, disk dolması veya yetkisiz erişim gibi riskleri erken yakalamaktır.

Doğrulama testi: canlıya geçmeden önce

Sunucunun hazır olduğunu anlamak için yalnız servis durumuna bakmak yetmez. En az bir temel sorgu, bir dosya ve disk kontrolü, bir de yedek geri dönme denemesi yapın. Örneğin bellek ve disk düzeni için aşağıdaki komutlar işinize yarar:

free -h
lsblk
df -h

Beklenen durum; RAM’in görülebilir olması, disklerin planladığınız bölümleme ile bağlanması ve dosya sistemi doluluk oranlarının kabul edilebilir seviyede kalmasıdır. Ardından veritabanı tarafında küçük bir okuma-yazma testi çalıştırın. Uygulama trafiğini temsil eden birkaç sorgu ile gecikmeyi ölçün; amaç mutlak hız değil, öngörülebilir davranıştır.

Eğer test sırasında bağlanamama, beklenmedik gecikme veya hata alırsanız, önce firewall, bind adresi, servis adı ve disk doluluğunu kontrol edin. Sorunun çoğu zaman işletim sistemi katmanında mı yoksa veritabanı katmanında mı oluştuğunu ayırmak, gereksiz yeniden kurulumdan daha değerlidir.

Sık sorunlar ve güvenli geri dönüş

En sık karşılaşılan sorunlardan biri, sunucunun kurulumdan sonra dışarıya açık hale gelmesi ama uygulama IP’sinin whitelist’e eklenmemesidir. Bu durumda bağlantı reddi görülür; çözüm portu herkese açmak değil, doğru kaynağı izin listesine eklemektir. Diğer bir sorun disklerin erken dolmasıdır. Özellikle log ve yedek aynı diskteyse, sistem kısa sürede yavaşlar. Bu senaryoda önce yazma yoğunluğunu düşürmek, sonra eskiyip gereksiz büyüyen logları kontrol etmek gerekir.

Geçiş sırasında performans beklentiyi karşılamazsa, geri dönüş planı önceden hazır olmalıdır. Eski veritabanı sunucusunu tamamen kapatmadan canlı tutun, uygulama bağlantısını geri çevirin ve yeni sunucuyu izole halde incelemeye alın. Kesin veri tutarlılığı için küçük bir işlem setiyle hem okuma hem yazma kontrolü yapın. Eğer kiralamayı sonlandırmanız gerekiyorsa, diskleri güvenli biçimde temizlemeden erişimi kapatmayın.

Son kontrol listesi

• Veri boyutu, büyüme hızı ve yoğun saatler not edildi mi?
• Disk, RAM, CPU ve ağ seçimi iş yüküne göre yapıldı mı?
• Veritabanı servisi adı doğrulandı mı?
• Firewall yalnız izinli adreslere açık mı?
• Yedekleme hedefi ve geri yükleme testi hazır mı?
• Temel sorgu hızlı ve hatasız çalışıyor mu?
• Geri dönüş için eski bağlantı planı saklanıyor mu?

Bu maddeler tamamlanmadan sunucuyu canlı kabul etmeyin. Fiziksel sunucu kiralamanın gerçek değeri, yalnız performans değil, operasyonu da kontrol edebilmenizdir. Kontrolün olmadığı yerde yüksek donanım tek başına güven vermez.