Sıfır Kesinti ile Veritabanı Geçişi: Stratejiler, Örnekler ve Uygulama

Son Güncelleme: Mayıs 2026

Veritabanı geçişi (database migration) sırasında kullanıcı deneyimini korumak, uygulama erişilebilirliğini sağlamak ve veri bütünlüğünü bozacak hatalardan kaçınmak kritik önemdedir. Bu rehberde sıfır kesinti (zero-downtime) hedefiyle uygulanabilecek stratejiler, ön koşullar, MySQL ve PostgreSQL için pratik örnekler, test ve rollback (geri alma) adımları ile Corelux hizmetlerine nasıl entegre edileceği ayrıntılı olarak anlatılacaktır.

İçindekiler

• Sıfır Kesinti Veritabanı Geçişi Nedir?
• Ana Geçiş Stratejileri
• Planlama ve Ön Koşullar
• MySQL İçin Örnek: Replika ve Switch
• PostgreSQL İçin Örnek: Logical Replication
• Strateji Karşılaştırma Tablosu
• Test, İzleme ve Rollback Adımları
• Performans, Kilitlenmeler ve İyileştirme
• Sıkça Sorulan Sorular
• Sonuç

Sıfır Kesinti Veritabanı Geçişi Nedir?

Sıfır kesinti hedefi, uygulamanın kullanıcılarına (son kullanıcılar) herhangi bir hizmet kesintisi yaşatmadan bir veritabanını başka bir sunucuya, depolama tipine veya sürüme taşımaktır. Bu süreçte amaç; veri tutarlılığını, yazma-okuma sürekliliğini ve performansı korumaktır. Tipik kullanım senaryoları:

• Donanım yükseltmesi: SSD/NVMe veya farklı RAID düzenine geçiş.
• Buluta geçiş: Fiziksel sunucudan bulut sunucuya veya kiralık sunucudan VPS/VDS ortamına taşıma.
• Sürüm yükseltme: Major veritabanı sürüm değişiklikleri (ör. MySQL 5.7 → 8.0).
• Coğrafi taşıma: Yeni veri merkezi veya farklı ülke üzerinde servis verme.

Ana Geçiş Stratejileri

Aşağıdaki stratejiler genellikle kesintisiz geçiş sağlamak için kullanılır. Her birinin avantajları ve kısıtları vardır.

• Replika (Replica) ve Switch: Var olan veritabanının replikasını yeni sunucu üzerinde oluşturup senkronize olduktan sonra yazma trafiğini yeni sunucuya yönlendirme.
• Blue-Green (Mavi-Yeşil) Deploy: İki paralel ortam bulundurup trafik geçişi ile yeni ortama sorunsuz geçiş sağlama.
• Logical Replication / CDC (Change Data Capture): Değişiklikleri olay bazlı başka hedeflere yansıtma — PostgreSQL logical replication, Debezium, Maxwell gibi araçlar.
• Dual Write ve Shadow Tables: Uygulamanın aynı anda hem eski hem yeni veritabanına yazması; daha sonra yeni yapı doğrulanınca eskiyi bırakma.
• Minimal İndis (Schema) Değişiklikleri ile Rolling Migrations: Şemayı geriye dönük uyumlu şekilde parçalarla güncelleme.

Planlama ve Ön Koşullar

Başarılı bir sıfır kesinti geçişi ayrıntılı planlama gerektirir. Aşağıdaki maddeler mutlaka değerlendirilmelidir:

• Yedekleme: Tam yedek (backup) alın ve yedeklerin doğrulanmasını yapın. Corelux'un Yedekleme Hizmeti bu noktada entegre edilebilir.
• Rehberli Testler: Test ortamında tam bir geçiş provası yapın.
• İzleme: Replika gecikmesi (replication lag), I/O, CPU, ağ gecikmesi ve uygulama hatalarını izleyin.
• Rollback Planı: Başarısızlık senaryoları için net adımlar hazırlayın.
• Uygulama Hazırlığı: Uygulamanın connection stratejilerini, retry ve timeouts ayarlarını düzenleyin.
• DNS ve Bağlantı Yönlendirme: Trafiği yönlendirmek için load balancer veya connection string güncellemeleri planlayın. Gerektiğinde Corelux'un Sanal Sunucu veya Kiralık Sunucu servisleri kullanılabilir.

MySQL İçin Örnek: Replika Oluşturma ve Trafik Switch

En yaygın yöntemlerden biri asenkron/yarı-senkron replikasyon ile yeni hedefte tam bir replika oluşturup sonra yazma trafiğini bu replika üzerine almak (switchover) yöntemidir. Adımlar özetle:

1. Hazırlık: Kaynak sunucuda FLUSH TABLES WITH READ LOCK; ile kısa süreli kilitleme, ardından binlog pozisyonunu veya GTID bilgisini kaydetme.
2. Veri kopyalama: mysqldump ya da Percona XtraBackup ile veri transferi. Örnek mysqldump komutu:

mysqldump -u root -p --single-transaction --master-data=2 --routines --triggers --databases mydb > mydb.sql

Alternatif olarak online yedek ve hızlı restore için Percona XtraBackup tercih edilebilir.

3. Replika yapılandırma: Hedefte dump dosyasını yükleyip, kaynak binlog pozisyonu veya GTID kullanılarak CHANGE MASTER TO ... ile replikasyonu başlatın:

CHANGE MASTER TO 
  MASTER_HOST='source.host',
  MASTER_USER='repl',
  MASTER_PASSWORD='replpass',
  MASTER_LOG_FILE='mysql-bin.000123',
  MASTER_LOG_POS=456789;
START SLAVE;

Not: Replika lag (gecikme) metriğini izleyin: SHOW SLAVE STATUS\G çıktısındaki Seconds_Behind_Master değerine dikkat edin.

Replikasyon senkron hale geldiğinde, yazma trafiğini yeni sunucuya yönlendirmek için birkaç yaklaşım vardır:

• Failover işlemi: Uygulama konfigürasyonunda connection string'i yeni sunucuya güncelleyin veya load balancer üzerinde hedef değişikliği yapın.
• VIP (Virtual IP) veya NAT değişimi: IP yönlendirmesini (ör. keepalived) yeni sunucuya taşıyın.
• DNS TTL azaltma: Geçiş öncesi DNS TTL'yi düşük tutmak, hızlı yönlendirme sağlar.

Switch anında kısa süreli artan yazma gecikmesi veya bağlantı yenilenmeleri görülebilir; bu yüzden uygulama tarafında retry mantığı ve kısa süreli 5xx hatalarına tolerans olması beklenir.

PostgreSQL İçin Örnek: Logical Replication ile Online Geçiş

Logical replication, tablo düzeyinde değişiklikleri abone olan hedefe yansıtmanıza imkan verir. Major sürüm yükseltmeleri veya farklı donanım tipleri arasında geçişlerde ideal bir yöntemdir.

Örnek adımlar:

1. Kaynak ve hedef ayarları: Kaynakta wal_level = logical, uygun max_replication_slots ve max_wal_senders konfigürasyonlarını yapın.
2. Publication oluşturma:

-- kaynak sunucuda
CREATE PUBLICATION mypub FOR ALL TABLES;

3. Abonelik oluşturma:

-- hedef sunucuda
CREATE SUBSCRIPTION mysub
  CONNECTION 'host=source.host port=5432 dbname=mydb user=replicator password=replpass'
  PUBLICATION mypub;

İlk snapshot büyük veri setlerinde uzun sürebilir; bu nedenle minimal tablo seti ile başlayıp, kritik olmayan tabloları sonradan eklemek mantıklıdır. Geçiş sırasında uygulama yazma hedefini yeni veritabanına almadan önce veri tutarlılığını kontrol edin.

Strateji Karşılaştırma Tablosu

Test, İzleme ve Rollback Adımları

Her geçişte test ve izleme kritik rol oynar. Önerilen kontroller:

• Veri tutarlılığı kontrolü: Örnek olarak satır sayıları, checksum karşılaştırmaları. Basit bir checksum kontrolü örneği:

-- örnek MySQL için
SELECT COUNT(*) FROM important_table;
-- veya
CHECKSUM TABLE important_table;

• İzleme metrikleri: Replika lag, QPS (queries per second), 95p response time, disk I/O ve ağ gecikmesi.
• Rollback: Eğer yeni hedefte kritik hatalar oluşursa, yazma trafiğini tekrar eski ana düğüme yönlendirin ve replikasyonu düzeltin. Rollback planı önceden test edilmelidir.

Performans, Kilitlenmeler ve İyileştirme

Geçiş sürecinde ortaya çıkabilecek performans sorunları ve çözümleri:

• Kilitler (locks): Büyük DDL (schema) değişiklikleri sırasında online DDL araçları (ör. gh-ost, pt-online-schema-change) kullanın.
• I/O patlamaları: Snapshot veya toplu insert işlemleri disk I/O'yu arttırır; IOPS limitlerini ve throttling politikalarını değerlendirin.
• Connection havuzu: Uygulama tarafında connection pool ayarlarını uygun şekilde ölçeklendirin; kısa süreli spike'larda pool büyüklüğünü kontrol edin.

Örnek: pt-online-schema-change ile online DDL:

pt-online-schema-change --alter "ADD COLUMN new_col VARCHAR(50)" D=mydb,t=users --execute

Sıkça Sorulan Sorular

Sonuç

Sıfır kesinti hedefiyle veritabanı geçişleri iyi bir planlama, test ve izleme gerektirir. Replica ve switch, logical replication, blue-green ve dual-write gibi stratejilerin doğru kombinasyonu ile kullanıcı deneyimini koruyarak taşıma gerçekleştirebilirsiniz. Her adımda yedekleme, izleme ve rollback planı hazır bulundurun.

Eğer taşıma için sunucu altyapısı veya yedekleme çözümleri arıyorsanız Corelux'un Kiralık Sunucu, Sanal Sunucu ve Yedekleme Hizmeti sayfalarını inceleyerek teknik ekiplerimizle iletişime geçebilirsiniz. Geçiş öncesi ücretsiz ön değerlendirme ve test desteği almak için Corelux ile irtibata geçin.