Sanal Sunucularda Büyük Veritabanlarını Yönetmek

Büyük veritabanları VPS üzerinde neden farklı davranır?

Sanal özel sunucu (VPS), size fiziksel bir makinenin bir dilimini verir: belirli sayıda sanal işlemci, sabit miktarda RAM ve çoğu zaman ağ üzerinden bağlanan ya da diğer müşterilerle paylaşılan bir disk. Küçük veritabanları bu sınırları pek fark etmez. Ancak bir veritabanı onlarca veya yüzlerce gigabayta ulaştığında ya da çok sayıda eşzamanlı sorguyu işlemeye başladığında, sanal ortamın kısıtları performansı belirleyen ana etken haline gelir.

İyi haber şu ki sorunların çoğu öngörülebilir kalıplar izler. Bu rehber, bir VPS’in veritabanı için nasıl boyutlandırılacağını, önce hangi ayarların düzenleneceğini, depolama ve yedeklerin nasıl yönetileceğini ve tek bir sunucunun ötesine ne zaman geçmek gerektiğini ele alıyor. Örneklerde VPS paketlerinde en sık çalıştırılan iki motor olan MySQL/MariaDB ve PostgreSQL kullanılıyor.

Sunucuyu boyutlandırmak: RAM, CPU ve disk

Evrensel bir formül yoktur, ancak verileriniz ile kaynaklarınız arasındaki ilişki size çok şey anlatır.

Bellek

Veritabanları verileri ve indeksleri bellekte önbelleğe alır. “Çalışma kümesi”, yani düzenli olarak okunan veriler RAM’e sığdığında sorguların çoğu diske hiç uğramaz. Sığmadığında ise her önbellek ıskalaması bir disk okumasına dönüşür ve performans keskin biçimde düşebilir. Toplam veritabanı boyutu kadar RAM’e ihtiyacınız yoktur; sıcak verileri tutacak kadar, artı bağlantılar, sıralama işlemleri ve işletim sistemi için pay bırakacak kadar belleğe ihtiyacınız vardır.

CPU

CPU; karmaşık sorgular, çok sayıda eşzamanlı bağlantı ve sıkıştırma için önemlidir. Paylaşımlı sanal sunucularda paketinizin ayrılmış mı yoksa paylaşımlı vCPU mu sunduğunu kontrol edin; paylaşımlı çekirdekler komşular yoğunken kısıtlanabilir ve bu durum tutarsız sorgu sürelerinde kendini gösterir.

Disk

Veritabanı iş yükleri küçük, rastgele okuma ve yazmalardan oluşur; bu yüzden gecikme ve IOPS, sıralı aktarım hızından çok daha önemlidir. Büyük veritabanları için SSD veya NVMe depolama fiilen bir zorunluluktur. Web hosting performansında SSD’ler yazımız bunun nedenini açıklar.

Temel ayarları düzenlemek

Varsayılan yapılandırmalar küçük makinelerde de çalışabilmeleri için bilinçli olarak temkinlidir. Daha büyük bir sunucuda faydanın büyük kısmını birkaç ayar sağlar. Her seferinde tek bir şeyi değiştirin ve sonucu ölçün.

MySQL ve MariaDB (InnoDB)

• innodb_buffer_pool_size: ana veri ve indeks önbelleği. Yalnızca veritabanına ayrılmış bir sunucuda yaygın bir başlangıç noktası, işletim sistemi ve bağlantılar için pay bırakarak RAM’in kabaca yarısı ile dörtte üçü arasıdır.
• innodb_log_file_size (yeni MySQL sürümlerinde innodb_redo_log_capacity): daha büyük redo günlükleri yoğun yazma yüklerini dengeler.
• max_connections: gerçekçi tutun; her bağlantı bellek kullanır.

[mysqld]
innodb_buffer_pool_size = 12G
innodb_redo_log_capacity = 2G
max_connections = 200
slow_query_log = 1
long_query_time = 1

PostgreSQL

• shared_buffers: PostgreSQL işletim sisteminin sayfa önbelleğine de dayandığından, bu değer başlangıç olarak çoğu zaman RAM’in yaklaşık dörtte biri olarak ayarlanır.
• effective_cache_size: önbellekleme için toplamda ne kadar bellek bulunduğunu belirten bir planlayıcı ipucu.
• work_mem: her sıralama veya hash işlemi için ayrılan bellektir ve bir sorguda birkaç kez kullanılabilir; bu yüzden dikkatle artırın.

shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 32MB
maintenance_work_mem = 1GB
log_min_duration_statement = 1000

Bu örnek değerler, yaklaşık 16 GB RAM’i veritabanına ayrılmış bir sunucuyu varsayar. Bunlar iş yükünüz için öneri değil, yalnızca örnektir; ayar adları ve varsayılanlar sürümden sürüme değiştiği için motorunuzun sürümüne ait belgeleri kontrol edin.

Değişiklikleri güvenle uygulamak

Yapılandırma dosyasını düzenlemeden önce bir kopyasını alın ve değişikliğin yeniden başlatma gerektirip gerektirmediğini öğrenin. Bazı ayarlar çalışırken yeniden yüklenebilirken buffer pool veya shared_buffers gibi bellek ayarları çoğu zaman yeniden başlatma ister. Bu işlemi trafiğin düşük olduğu bir saate planlayın ve yeniden başlattıktan sonra hata günlüğünü kontrol edin; yanlış yazılmış tek bir satır, veritabanının hiç açılmamasına neden olabilir.

İndeksler, sorgular ve şema

Donanım ve ayarlar ancak bir yere kadar yardımcı olabilir. Büyük veri kümelerinde tek bir eksik indeks, milisaniyelik bir sorguyu gigabaytlarca veri okuyan tam bir tablo taramasına dönüştürebilir. Şu alışkanlıkları rutin haline getirin:

• Yavaş sorgu günlüğünü etkinleştirin ve düzenli olarak inceleyin.
• Sorguların gerçekte nasıl yürütüldüğünü görmek için EXPLAIN (PostgreSQL’de EXPLAIN ANALYZE) kullanın.
• Sık kullanılan WHERE, JOIN ve ORDER BY ifadelerindeki sütunları indeksleyin; ancak her şeyi indekslemekten kaçının, çünkü her indeks yazmaları yavaşlatır ve yer kaplar.
• Eski verileri arşivleyin veya bölümleyin. Zamana dayalı bölümleme, devasa silme işlemleri yerine eski ayları ucuza kaldırmanızı sağlar.
• PostgreSQL’de autovacuum’un yetiştiğinden emin olun; büyük ve sık güncellenen tablolardaki şişkinlik zamanla performansı düşürür.

Büyük tablolarda şema değişiklikleri

Yüz milyonlarca satırlık bir tabloya sütun veya indeks eklemek tabloyu kilitleyebilir ya da saatlerce sürebilir. Motor sürümünüzün ihtiyaç duyduğunuz işlem için çevrimiçi veya anlık şema değişikliklerini destekleyip desteklemediğini kontrol edin, değişikliği önce üretim verisinin bir kopyasında test edin ve sakin bir döneme planlayın. MySQL için çevrimiçi şema değişikliği araçları bu amaçla yaygın olarak kullanılır; PostgreSQL’de ise CREATE INDEX CONCURRENTLY, indeks oluşturulurken yazmaların engellenmesini önler.

Depolama düzeni ve disk yönetimi

Büyük veritabanları, özellikle ikili günlükler (binary log), WAL günlükleri, geçici dosyalar ve yerel yedekler de hesaba katıldığında diskleri beklenenden hızlı doldurur. Alanın tükenmesi veritabanını durdurabilir ve kötü durumlarda veri bozulması riski doğurabilir.

• Veri ve yedekler için ayrı diskler, boyutlandırmayı kolaylaştırır ve yedeklerin veri diskini doldurmasını önler.
• Günlük saklama sürelerini belirleyin: MySQL ikili günlükleri için saklama süresi ayarlayın ve özellikle replikasyon slotları kullanılıyorsa PostgreSQL WAL büyümesini takip edin.
• Boş alan için uyarı kurun; alan bitmeden çok önce, örneğin yüzde 80 ve yüzde 90 doluluk seviyelerinde.
• Sağlayıcınızın sınırlarını bilin. Bazı VPS paketleri disk başına IOPS veya aktarım hızını sınırlar; daha büyük diskler veya üst paketler bu sınırları yükseltebilir.

df -h
iostat -x 5
du -sh /var/lib/mysql /var/lib/postgresql

Yedekleme ve kurtarma

Büyük bir veritabanında yedekleme stratejisi performans kadar önemlidir. Bir plan iki soruyu yanıtlamalıdır: ne kadar veri kaybını göze alabilirsiniz ve ne kadar süre kapalı kalmayı kaldırabilirsiniz?

Mantıksal yedekler

mysqldump veya pg_dump gibi araçlar verileri SQL ya da arşiv dosyası olarak dışa aktarır. Taşınabilir ve basittirler, ancak veritabanı büyüdükçe oluşturulmaları ve özellikle geri yüklenmeleri yavaşlar.

Fiziksel yedekler

MySQL ailesi veritabanları için Percona XtraBackup veya MariaDB Backup, PostgreSQL için pg_basebackup gibi araçlar veri dosyalarını doğrudan kopyalar. İkili günlükler veya WAL arşivleme ile birleştirildiğinde belirli bir ana geri dönüşü (point-in-time recovery) desteklerler.

Anlık görüntüler

Sağlayıcının disk anlık görüntüleri (snapshot) pratiktir, ancak çalışan bir veritabanının anlık görüntüsü ancak motor ondan tutarlı biçimde kurtarılabiliyorsa güvenlidir. Bunlara güvenmeden önce sağlayıcınızın yönergelerini kontrol edin ve geri yüklemeyi test edin.

pg_dump -Fc -d appdb -f /backup/appdb.dump
mysqldump --single-transaction --routines appdb | gzip > /backup/appdb.sql.gz

Hangi yöntemi kullanırsanız kullanın, kopyaları sunucunun dışında, tercihen farklı bir sağlayıcıda veya bölgede tutun ve düzenli test geri yüklemeleri planlayın. Hiç geri yüklemediğiniz bir yedek bir plan değil, bir varsayımdır.

İzleme ve bakım

Tek anlara değil eğilimlere bakın. Faydalı metrikler arasında önbellek isabet oranı, saniye başına sorgu sayısı, yavaş sorgular, replikasyon gecikmesi, kullanılan bağlantılar, disk alanı, I/O bekleme ve bellek baskısı yer alır. Birçok izleme altyapısının hazır veritabanı panoları vardır; disk alanı ve replikasyon durumu için uyarı veren basit betikler bile en yaygın kesintileri önler.

Veritabanını çevreleyen altyapıyı da unutmayın. Süresi dolmuş bir VPS paketi, ödenmemiş bir fatura veya yenilenmemiş bir alan adı, bir uygulamayı çöken bir veritabanı kadar etkili biçimde çevrimdışı bırakabilir. TLDix, hosting ve alan adı yenilemelerini hosting panelinde birlikte takip etmenizi sağlar; böylece veritabanlarınızın arkasındaki sunucuların yenileme tarihleri hafızaya kalmaz.

Tek bir VPS’in ötesine ne zaman geçmeli?

İyi ayarlanmış tek bir sunucu çok şeyi kaldırır, ancak onu aştığınızın işaretleri şunlardır: çalışma kümesinin bütçenize uygun en büyük pakete artık sığmaması, sorgu optimizasyonundan sonra bile CPU’nun sürekli dolu olması ya da yedekleme ve geri yükleme sürelerinin kurtarma hedeflerinizi aşması.

Karmaşıklık sırasına göre kabaca yaygın sonraki adımlar:

1. Dikey ölçekleme: daha fazla RAM ve daha hızlı depolama sunan büyük bir pakete geçin.
2. Okuma replikaları: raporlama ve okuma ağırlıklı trafiği bir veya daha fazla replikaya yönlendirin.
3. Bağlantı havuzu: PgBouncer veya ProxySQL gibi araçlar, çok sayıda kısa ömürlü bağlantının yükünü azaltır.
4. Önbellek katmanı: sık kullanılan sorgu sonuçlarını bellek içi bir önbellekte saklayın.
5. Yönetilen veritabanı hizmetleri veya sharding, gerçekten tek bir makineyi aşan iş yükleri için.

Bir sonraki aşama için yeni bir sağlayıcı seçiyorsanız, en iyi web hostingi seçme rehberimiz depolama, destek ve yükseltme seçenekleri hakkında sorulmaya değer soruları ele alır.