Bir yazılım mühendisinin kabusu nedir diye sorsanız, birçoğu “canlıdaki veritabanı şemasını değiştirmek” diyecektir. Uygulamanız büyüdükçe, yeni özellikler eklendikçe veritabanı tablolarınızın yapısını değiştirmeniz gerekir. Ancak bu işlem sırasında bir hata yaparsanız, siteniz saatlerce kapalı kalabilir veya daha kötüsü, yılların verisi bir anda buharlaşabilir.
Peki, profesyonel ekipler binlerce kullanıcının aktif olduğu bir sistemde nasıl hiç kimse fark etmeden veritabanı değişikliği yapıyor? İşte Zero-downtime (sıfır kesinti) migration dünyasına yolculuğumuz başlıyor.
Migration Nedir? Neden Korkutur?
Veritabanı migration (göç), veritabanı şemasının (tablolar, kolonlar, indeksler) versiyonlanmış bir şekilde güncellenmesi sürecidir. Korkutucudur çünkü kodunuzu geri almak (rollback) kolaydır ama veritabanındaki hatalı bir DROP COLUMN komutunu geri almak, eğer yedeğiniz yoksa imkansıza yakındır.
Hazırlık: Schema Versioning ve Araçlar
İlk kural: Veritabanı değişikliklerini asla elle (manuel) yapmayın. Her değişiklik bir “migration dosyası” içinde kodlanmalı ve versiyon kontrol sistemine (Git) dahil edilmelidir.
- Araçlar: Prisma, TypeORM, Flyway veya Liquibase gibi araçlar bu süreci otomatiğe bağlar.
- Rollback Strategy: Her migration dosyası, yaptığı işi geri alan bir “down” fonksiyonuna sahip olmalıdır. “Eğer işler ters giderse nasıl eski haline dönerim?” sorusunun yanıtı önceden yazılmış olmalıdır.
Zero-Downtime Stratejileri: “Expand and Contract”
Canlı bir sistemi kapatmadan şema değiştirmek için kullanılan en yaygın yöntem “Genişlet ve Daralt” stratejisidir. Diyelim ki bir kolonu ismini değiştirmek istiyorsunuz. Bunu tek adımda yaparsanız, kodunuz eski ismi beklerken veritabanı yeni ismi vereceği için uygulama çöker.
Doğru Adımlar:
- Genişlet (Expand): Veritabanına yeni kolon ismini ekleyin ama eski kolonu silmeyin.
- Çift Yazma (Double Writing): Uygulama kodunuzu güncelleyin; artık veriyi hem eski kolona hem de yeni kolona yazsın.
- Veri Taşıma (Migrate): Eski kolondaki mevcut verileri bir script yardımıyla yeni kolona taşıyın.
- Okumayı Değiştir: Uygulamayı, veriyi artık sadece yeni kolondan okuyacak şekilde güncelleyin.
- Daralt (Contract): Her şeyin doğru çalıştığından emin olduktan sonra (birkaç gün sonra), eski kolonu güvenle silebilirsiniz.
Bu yöntem biraz uzun sürer ama risk oranını neredeyse sıfıra indirir.
SQL vs NoSQL: Geçişin Farklı Yüzleri
- SQL (İlişkisel): Şema katıdır. Her değişiklik öncesinde veritabanı kilitlenebilir (lock). Bu yüzden migration işlemleri genellikle trafiğin en az olduğu saatlerde planlanır.
- NoSQL (Doküman Tabanlı): Şemasızdır, bu yüzden migration daha esnektir. Ancak bu sefer de “kod tarafında migration” yapmanız gerekir. Uygulamanız eski ve yeni veri formatlarını aynı anda okuyabilecek yetenekte olmalıdır.
Test Süreci: Staging’in Önemi
Canlı veritabanına dokunmadan önce mutlaka bir Staging (hazırlık) ortamında test yapın. İdeal olarak, Staging veritabanınız, canlı veritabanınızın bir kopyası (anonimleştirilmiş verilerle) olmalıdır. Eğer migration milyonlarca satırlık bir tabloda 10 saniyeden uzun sürüyorsa, bu canlı sistemde büyük bir soruna yol açabilir. Bu tür durumlarda indekslemeleri ve tablo kilitlerini önceden analiz etmelisiniz.
Altın Kural: Yedek Alın!
Ne kadar uzman olursanız olun, ne kadar test yaparsanız yapın, canlı sistemde her zaman beklenmedik bir şeyler olabilir. Migration komutunu çalıştırmadan hemen önce alınmış taze bir yedek (backup), kariyerinizi kurtarabilir.
Özetle: Veritabanı migration süreci, bir cerrahın titizliğiyle yürütülmelidir. Değişiklikleri versiyonlayın, küçük adımlarla (double writing) ilerleyin ve her zaman bir kaçış planınız (rollback) olsun. 2026’da “sistem bakım nedeniyle kapalıyız” yazısı görmek istemiyorsanız, bu stratejileri şimdiden mimarinize dahil edin.
