Veritabanı Sunucusu: MySQL ve PostgreSQL İçin VDS Rehberi

Ayrı bir veritabanı sunucusu, uygulamanın verilerini tutan MySQL, MariaDB ya da PostgreSQL’i web sunucusundan bağımsız, yalnızca bu işe ayrılmış bir makinede çalıştırma düzenidir. Uygulamayla aynı makinedeki veritabanı, trafik büyüdükçe işlemciyi ve belleği PHP ya da Node.js süreçleriyle paylaşmak zorunda kalır; ilk darboğaz çoğu zaman burada oluşur ve ayrı sunucu bu çekişmeyi ortadan kaldırır.

Bu iş için en uygun zemin, kaynakları başka müşterilerle paylaşılmayan bir sanal sunucudur. VDS sunucu üzerinde çalışan veritabanı, gün içindeki yoğunluktan bağımsız olarak aynı sorguyu benzer sürede yanıtlar; uygulama katmanı ise daha ekonomik bir VPS sunucu ya da birden fazla sunucu üzerinde kalabilir.

Veritabanını neden ayrı bir sunucuya taşımalı?

Veritabanını ayrı bir sunucuya taşımak kaynak çekişmesini bitirir, saldırı yüzeyini küçültür ve her katmanı kendi ihtiyacına göre büyütmenizi sağlar:

• Kaynak yalıtımı: Ani bir trafik artışında PHP işçileri belleği tüketse bile veritabanının önbelleği yerinde kalır.
• Bağımsız ölçekleme: Uygulama sunucusu sayısını artırırken veritabanını tek ve güçlü bir makinede tutabilirsiniz.
• Daha küçük saldırı yüzeyi: Veritabanı portu internete açılmaz; yalnızca uygulama sunucularının IP adresleri bağlanabilir.
• Ayrı bakım: Uygulama güncellemesi veritabanını yeniden başlatmayı gerektirmez.

Her proje için şart değildir. Tek sunucuda rahat çalışan ve veritabanı birkaç gigabaytı geçmeyen bir site için ayrı sunucu yalnızca ek maliyet ve ağ gecikmesi getirir. Ayrıştırmanın zamanı, veritabanının bellek ihtiyacı uygulamayla çakışmaya başladığında ya da birden fazla uygulama sunucusu planladığınızda gelir.

Veritabanı sunucusu için neden VDS tercih edilir?

Veritabanları işlemci zamanına, belleğe ve disk gecikmesine aynı anda duyarlıdır; VDS bu üç kaynağı komşu sanal makinelerin yükünden bağımsız hâle getirir. Paylaşımlı vCPU’da yoğun bir komşu, sorgu planlama ve sıralama gibi işlemci yoğun adımları beklettiğinde aynı sorgu sabah hızlı, akşam belirgin biçimde yavaş çalışabilir. LIONFIN VDS paketlerinde çekirdek, bellek ve disk tamamen size ayrıldığı için önbellek boyutunu ve sorgu sürelerini planlamak kolaylaşır.

Disk tarafında asıl ölçüt hız değil gecikmedir. InnoDB varsayılan ayarlarla her işlemi (commit) kalıcı kılmak için redo log’u diske yazıp fsync çağırır; PostgreSQL aynı işi WAL kaydıyla yapar. Yazma yoğun uygulamalarda her işlem bu disk onayını beklediğinden düşük gecikmeli NVMe disk doğrudan daha fazla işlem/saniye anlamına gelir.

Ayrılmış kaynağın teknik anlamı VDS nedir yazısında, paylaşımlı modelle farkı ise steal time ölçümüyle birlikte VPS VDS farkı yazısında anlatılır.

MySQL/MariaDB mi PostgreSQL mi?

Seçimi çoğu zaman uygulama yapar: WordPress, WooCommerce ve PHP tabanlı birçok hazır yazılım MySQL ya da MariaDB ister; karmaşık sorgular, coğrafi veri ya da gelişmiş JSON işlemleri gereken özel projelerde PostgreSQL öne çıkar.

MariaDB, MySQL’den ayrılmış bir projedir ve yaygın uygulamalarla büyük ölçüde uyumludur; yeni sürümlerde bazı özellikler ayrıştığı için birinden diğerine geçmeden önce uygulamanızın destek listesine bakın.

Bellek ayarları: buffer pool ve shared_buffers ne kadar olmalı?

Yalnızca veritabanı çalıştıran bir sunucuda yaygın başlangıç noktası, innodb_buffer_pool_size değerini RAM’in %50–70’ine; PostgreSQL’de shared_buffers değerini RAM’in yaklaşık %25’ine, effective_cache_size değerini %50–75’ine ayarlamaktır. PostgreSQL işletim sisteminin dosya önbelleğine de güvendiği için kendi arabelleğini daha küçük tutar. 16 GB RAM’li bir VDS için örnek değerler (sunucuda hangi veritabanı varsa yalnızca onunkini uygulayın):

# MariaDB: /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 10G

# PostgreSQL: /etc/postgresql/16/main/postgresql.conf
shared_buffers = 4GB
effective_cache_size = 10GB
work_mem = 16MB

PostgreSQL yolundaki 16 kurulu sürüme göre değişir; MySQL’de aynı ayar /etc/mysql/mysql.conf.d/mysqld.cnf dosyasına yazılır. work_mem her sıralama ve birleştirme işlemi için ayrı ayrı ayrıldığından yüksek tutulursa çok bağlantılı sistemlerde belleği hızla tüketir. Değişiklikten sonra servisi yeniden başlatın ve bellek baskısında veritabanı sayfalarının swap’e itilmemesi için vm.swappiness değerini düşük tutun.

Veritabanı sunucusu nasıl güvenli hâle getirilir?

Temel kural, veritabanı portunu internete hiç açmamak ve yalnızca uygulama sunucularının belirli IP adreslerinden şifreli bağlantıya izin vermektir. Örnekte veritabanı sunucusunun özel IP adresi 10.0.0.5, uygulama sunucusununki 10.0.0.4’tür:

# MariaDB/MySQL ([mysqld] bölümü): yalnızca özel ağı dinle, TLS zorunlu
bind-address = 10.0.0.5
require_secure_transport = ON

# PostgreSQL: postgresql.conf ve pg_hba.conf
listen_addresses = 'localhost,10.0.0.5'
hostssl  uygulama_db  uygulama  10.0.0.4/32  scram-sha-256

# Güvenlik duvarı: yalnızca uygulama sunucusuna izin ver
sudo ufw allow from 10.0.0.4 to any port 3306 proto tcp
sudo ufw allow from 10.0.0.4 to any port 5432 proto tcp

MySQL ve MariaDB’de kullanıcıyı da aynı adresle sınırlayın: CREATE USER 'uygulama'@'10.0.0.4' IDENTIFIED BY 'GUCLU_PAROLA' REQUIRE SSL;. MySQL TLS sertifikalarını kurulumda kendiliğinden üretir; MariaDB’de sürüme göre ssl_cert ve ssl_key tanımlamanız gerekebilir; Debian ve Ubuntu’daki PostgreSQL paketlerinde ssl = on varsayılan olarak açıktır. Sunucular arasında özel ağ yoksa trafik genel IP üzerinden aynı kurallar ve zorunlu TLS ile taşınabilir. Kuralların ayrıntısı UFW firewall kurulumu rehberindedir.

Yedekleme ve replikasyon nasıl kurulur?

Veritabanı yedeği iki türdür: mantıksal döküm (SQL ya da arşiv dosyası) ve fiziksel kopya (veri dizininin tutarlı bir görüntüsü). Küçük ve orta boyutlu veritabanları için döküm yeterlidir; büyük veritabanlarında fiziksel yedek geri yüklemeyi belirgin biçimde hızlandırır.

# MariaDB: mantıksal döküm (MySQL için aynı parametrelerle mysqldump)
sudo mariadb-dump --single-transaction --routines --triggers uygulama_db | gzip > uygulama_db-$(date +%F).sql.gz

# MariaDB: fiziksel yedek ve geri yüklemeye hazırlama
sudo mariadb-backup --backup --target-dir=/yedek/tam
sudo mariadb-backup --prepare --target-dir=/yedek/tam

# PostgreSQL: mantıksal ve fiziksel yedek
sudo -u postgres pg_dump -Fc uygulama_db > uygulama_db.dump
sudo -u postgres pg_basebackup -D /var/lib/postgresql/yedek -Ft -z -P

Yedekleri veritabanı sunucusunda bırakmayın; en az bir kopyayı farklı bir konuma aktarın ve geri yüklemeyi düzenli olarak deneyin. Mantığı 3-2-1 yedekleme kuralı yazısında anlatılır. Replikasyon ise yedeği tamamlar ama yerini tutmaz: MariaDB/MySQL’de binary log, PostgreSQL’de akış replikasyonu ile ikinci bir sunucu canlı kopyayı taşır, okuma sorgularını üstlenebilir ve arızada devreye alınabilir; yanlışlıkla silinen bir tablo ise replikaya da aynen yansır.

Yavaş sorgular nasıl izlenir?

Performans sorunlarının çoğu donanımdan değil, indekssiz ya da gereğinden geniş sorgulardan kaynaklanır; bu yüzden yavaş sorgu kaydı (slow query log) her veritabanı sunucusunda açık olmalıdır:

# MariaDB/MySQL ([mysqld] bölümü)
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 1

# PostgreSQL (postgresql.conf), süre milisaniye cinsinden
log_min_duration_statement = 1000
shared_preload_libraries = 'pg_stat_statements'

MariaDB kayıtlarını mariadb-dumpslow ya da Percona Toolkit’teki pt-query-digest ile özetleyebilirsiniz. PostgreSQL’de pg_stat_statements eklentisi, yeniden başlatmanın ardından CREATE EXTENSION pg_stat_statements; komutuyla etkinleşir ve en çok süre harcayan sorguları listeler. Bunlara ek olarak bağlantı sayısını, önbellek isabet oranını, replikasyon gecikmesini ve iostat -x 1 ile disk gecikmesini izleyin; genel sunucu metrikleri için Linux sunucu performans izleme rehberine bakabilirsiniz.