Database migrations: 'zero downtime' için blue-green deployment stratejileri

Uygulama katmanında blue-green deployment süreçlerini otomatize etmek görece kolay olsa da, database migration süreçleri sistemin state yapısı nedeniyle en büyük darboğazı oluşturur. Şema değişiklikleri, özellikle geriye dönük uyumluluğun kaybolduğu durumlarda, sistemin uptime süresini doğrudan etkiler. Bu darboğazı aşmak için veritabanı seviyesinde çift taraflı (dual-write) yazma ve kademeli migrasyon stratejilerini uygulamak gerekir.

Veritabanı şemasında geriye dönük uyumluluk

Zero downtime hedefi, uygulamanın hem eski hem de yeni veritabanı şemasıyla aynı anda çalışabilmesini gerektirir. Bu yaklaşım, migrasyon sürecini tek bir büyük operasyon yerine küçük, güvenli adımlara böler. İlk adım, veritabanına yeni bir kolon veya tablo eklerken mevcut kodun bu değişikliği görmezden gelmesini sağlamaktır.

Örneğin bir sütun ismini değiştirmek istediğinizde şu adımları izlemelisiniz: Önce yeni sütunu ekleyin, ardından hem eski hem de yeni sütuna yazma işlemi yapan bir kod bloğu deploy edin. Son aşamada ise okuma işlemlerini yeni sütuna taşıyın. Uygulama tarafındaki migration logic şu şekilde görünmelidir:

# İki sütuna aynı anda yazma (dual-write)
def save_user(user):
    # Eski sütuna yaz
    db.execute("UPDATE users SET old_col = %s WHERE id = %s", (user.val, user.id))
    # Yeni sütuna yaz
    db.execute("UPDATE users SET new_col = %s WHERE id = %s", (user.val, user.id))

Blue-green deployment ile veri senkronizasyonu

Blue-green deployment sırasında mavi (mevcut) ve yeşil (yeni) ortamların aynı veritabanı instance’ına bağlı olması risk taşır. Eğer yeşil ortam veritabanı şemasında yıkıcı (destructive) bir değişiklik yaparsa, mavi ortam anında çöker. Bu riski minimize etmek için veritabanını uygulama deployment döngüsünden ayırmak gerekir.

Bu senaryoda, veritabanını "sabit bir kaynak" olarak kabul edip, uygulamanın şema değişikliklerini yönetmesi için bir proxy katmanı veya CDC (Change Data Capture) mekanizmaları kullanmalısınız. Debezium gibi araçlar, veritabanı transaction loglarını izleyerek veriyi başka bir sisteme veya asenkron bir read-replica üzerine replike edebilir. Bu sayede yeşil ortam, kendi izole edilmiş veritabanı şemasıyla test edilirken mavi ortam mevcut trafiği karşılamaya devam eder.

Transaction log tabanlı replikasyon teknikleri

Uygulama kodunda dual-write yapmak istemiyorsanız, veritabanı seviyesinde replikasyon araçlarını kullanın. PostgreSQL’deki logical replication, belirli tabloların veya tüm veritabanının farklı bir şemaya sahip bir replikaya aktarılmasını sağlar. Bu yöntem, verinin sürekli olarak hedef (yeşil) veritabanına akmasını sağlar.

Şema değişikliği sırasında replikasyon slotları kullanılarak verinin tutarlılığı garanti altına alınır:

# Yeni bir logical replication slotu oluşturma
psql -c "SELECT pg_create_logical_replication_slot('migration_slot', 'pgoutput');"

# Replikasyon akışını başlatma
pg_recvlogical -d source_db --slot migration_slot --start -f -

Bu komutlar, sistemdeki her değişikliği bir stream olarak yakalar. Uygulama yeşil ortama geçtiğinde, replikasyon slotu üzerinden tüm güncel veriyi hazır bulur. Böylece kesinti süresi, sadece veritabanı bağlantılarını yeni instance’a çevirme süresi olan birkaç milisaniyeye iner.

Migration sonrası temizlik

Deployment tamamlandıktan sonra bırakılan dual-write kodları ve eski şema yapıları sistemde teknik borç oluşturur. Blue ortamın tamamen devre dışı bırakıldığından emin olduktan sonra, veritabanı tarafında artık kullanılmayan sütunları veya eski tabloları silmek (drop) gerekir. Bu işlemi yaparken mutlaka bir "rollback plan" hazır tutun.

Eğer bir sütunu silmeniz gerekiyorsa, önce kodu temizleyip o sütuna yazmayı bırakın. Ardından veritabanı yedeğini alın ve sütunu önce silmek yerine görünmez (invisible) hale getirin. Birkaç gün sistemin davranışını izledikten sonra sütunu fiziksel olarak drop edin. Bu yöntem, hatalı bir deployment durumunda veri kaybı yaşamadan geri dönmenizi sağlar.

Database migration sürecinde başarısızlığın ana nedeni genellikle veri tutarsızlığıdır. Bu yüzden her deployment aşamasında hem eski hem de yeni veritabanı arasında checksum tabanlı bir validasyon çalıştırın. Eğer veride kayma tespit edilirse, deployment’ı durdurmak veya trafiği otomatik olarak blue ortama geri yönlendirmek, sistemin bütünlüğünü korumak için en güvenli yoldur.