Canlı sistemlerde veritabanı migrasyonu planlama, tek seferlik script çalıştırmaktan ibaret değildir. Bu rehberde geri dönüş yolu, veri uyumu ve sıfır kesintiye yakın aşamalı geçişi nasıl kurgulayacağınızı adım adım ele alıyoruz.
Veritabanı migrasyonu planlama, birçok ekipte hâlâ “gece script çalıştırıp sabah kontrol ederiz” yaklaşımıyla ele alınıyor. Oysa canlı sistemlerde şema değişikliği; geri dönüş yolu, veri uyumu ve trafik altında kontrollü geçiş gerektiren bir mühendislik işidir. Bu rehberde migrasyonu tek seferlik bir komut olarak değil, aşamalı ve ölçülebilir bir plan olarak nasıl kurgulayacağınızı adım adım anlatıyoruz.
Amaç, kesintiyi mümkün olduğunca azaltmak kadar, bir sorun çıkarsa etkiyi sınırlı ve geri alınabilir tutmaktır. Aşağıdaki çerçeve hem küçük ekipler hem büyüyen ürünler için sadeleştirilebilir. Bu yaklaşım, KepezWeb’in özel yazılım ve bakım projelerinde de kullandığı kontrollü geçiş disipliniyle uyumludur.
Veritabanı Migrasyonu Planlama Neden Tek Script Değildir
Migrasyon çoğu zaman “ALTER TABLE çalıştır” adımına indirgenir. Bu bakış, düşük trafikli veya bakım penceresi olan sistemlerde işe yarayabilir. Canlı kullanıcı, arka plan işleri, raporlama ve entegrasyonlar devreye girdiğinde tablo değişir.
Gerçek riskler genellikle şema sözdiziminden değil, şu noktalardan gelir:
- Eski uygulama kodunun yeni kolon veya kısıtla uyumsuz çalışması
- Kilit sürelerinin uzaması ve istek kuyruğunun birikmesi
- Veri dönüşümünün yarım kalması
- Geri dönüş senaryosunun hiç yazılmamış olması
İyi bir plan; “ne değişecek” sorusundan önce “hangi sürümler aynı anda çalışacak” ve “yanlış giderse hangi adımı geri alacağız” sorularını yanıtlar.
Sıfır Kesinti Hedefini Gerçekçi Tanımlamak
Sıfır kesinti, her satırın ve her isteğin hiç etkilenmemesi anlamına gelmek zorunda değildir. Pratikte hedef genelde şudur: kullanıcıya yansıyan hata oranı ve yanıt süresi bozulmadan şema ve veri geçişini tamamlamak.
Bazı değişiklikler doğası gereği daha risklidir:
- Büyük tabloda indekssiz tarama gerektiren dönüşümler
- Zorunlu kolon ekleme ve anında doldurma
- Birincil anahtar veya benzersiz kısıt değişimleri
- Veritabanı motoru veya majör sürüm yükseltmesi
Bu durumlarda “sıfır kesinti” yerine “kontrollü, düşük etkili geçiş” hedefi daha dürüst ve yönetilebilir olur. Planın dili net olmalıdır: kabul edilebilir hata eşiği, yavaşlama eşiği ve durdurma koşulları yazılır.
Migrasyon Öncesi Envanter ve Bağımlılık Haritası
Değişikliğe başlamadan önce envanter çıkarın. Bu adım sık atlanır; oysa sonradan çıkan sorunların çoğu gizli bağımlılıktan kaynaklanır.
- Etkilenen tablolar, kolonlar, indeksler ve kısıtlar
- Bu tablolara yazan ve okuyan uygulama servisleri
- Zamanlanmış işler, kuyruk tüketicileri, rapor sorguları
- Harici entegrasyonlar ve okuma replikaları
- Yedekleme, geri yükleme yolu ve disk kapasitesi durumu
Özellikle e-ticaret sitesi gibi stok, sipariş ve ödeme tablolarının iç içe geçtiği sistemlerde tek bir şema adımı birden fazla iş akışını bozabilir. Envanteri yazılı hale getirmek, “kim ne zaman deploy edecek” kararını da netleştirir.
Kimlik ve oturum tabloları değişecekse, kimlik doğrulama ve yetkilendirme katmanının oturum ömrü, token yenileme ve rol okuma davranışını da plana dahil edin.
Geri Dönüş Yolunu Baştan Tasarlamak
Geri dönüş, migrasyon bittikten sonra düşünülecek bir “B planı” değildir. Her ileri adımın geri adımı, mümkünse migrasyon başlamadan önce tanımlanır.
- Geri dönüşün veri kaybı yaratıp yaratmayacağını açık yazın
- Yalnızca şema geri alma yetmez; uygulama sürümüyle birlikte geri dönmek gerekebilir
- Geri dönüş kararını kim verir, hangi metrik tetikler, bunu önceden netleştirin
- Geri dönüş testini staging ortamında en az bir kez oynatın
Bazı değişiklikler geri alınamaz veya çok pahalıdır: kolon silme, geri dönüşümsüz veri dönüşümü gibi adımlar buna girer. Bu adımları mümkünse geçişin sonuna, doğrulama tamamlandıktan sonraya bırakın.
KepezWeb olarak özel yazılım projelerinde migrasyon planını “ileri script + geri script + izleme metrikleri” üçlüsüyle ele almayı tercih ediyoruz. Script tek başına yeterli değildir; karar eşiği de planda yer almalıdır.
Aşamalı Şema Değişikliği ve Uyumluluk Katmanları
Canlı trafik altında güvenli geçişin temel fikri şudur: eski kod ve yeni kod bir süre aynı şema ile uyumlu çalışabilsin. Bu genelde expand–contract (genişlet–daralt) yaklaşımıyla yapılır.
- Genişletme: yeni kolon veya tabloyu ekleyin; henüz zorunlu yapmayın
- Kod uyumu: uygulama hem eski hem yeni alanı okuyup yazabilsin
- Veri doldurma: mevcut kayıtları arka planda backfill edin
- Doğrulama: tutarlılık kontrolleri ve metrikler yeşil olsun
- Daraltma: eski alanı kullanmayı bırakın, sonra kaldırın
Bu model, “tek seferde her şeyi değiştir” riskini parçalara böler. Her parça kendi başına geri alınabilir hale gelir.
| Yaklaşım | Kesinti riski | Geri dönüş | Ne zaman tercih edilir |
|---|---|---|---|
| Tek seferlik (big bang) | Yüksek | Zor ve riskli | Düşük trafik, kısa bakım penceresi |
| Aşamalı expand–contract | Daha düşük | Adım adım mümkün | Canlı üretim, sürekli trafik |
| Dual-write + backfill | Kontrollü | Planlı ve ölçülebilir | Veri dönüşümü gerektiren değişiklikler |
Canlı Trafikte Veri Uyumu: Dual-Write ve Backfill
Şema uyumlu olsa bile veri uyumu ayrı bir iştir. Özellikle kolon birleştirme, tip dönüşümü veya yeni türetilmiş alanlar için dual-write ve backfill birlikte düşünülür.
Dual-write: uygulama bir süre hem eski hem yeni alana yazar. Böylece canlı istekler yeni yapıyı besler.
Backfill: geçmiş kayıtlar arka planda, mümkünse küçük partiler halinde ve düşük öncelikli olarak dönüştürülür. Büyük tablolarda tek seferlik UPDATE kilidi ve replikasyon gecikmesi üretebilir.
- Backfill hızını trafik ve replika lag’e göre ayarlayın
- Idempotent (tekrar çalıştırılabilir) script kullanın
- Dönüşüm sonrası örneklem ve checksum ile tutarlılık doğrulayın
- Yazma çakışmalarında hangi alanın “kaynak gerçek” olduğunu netleştirin
Özel PHP/MySQL yazılım projelerinde sürüm numaralı migration dosyaları süreci disipline eder; ancak tool kullanmak, dual-write ve geri dönüş tasarımının yerine geçmez.
Test, İzleme ve Yayın Kontrol Listesi
Migrasyonu “çalıştı” diye kapatmayın. Yayın öncesi ve sonrası ölçüm çerçevesi planın parçasıdır.
Yayın öncesi
- Staging’de üretim benzeri veri hacmiyle prova
- Kilit süresi ve sorgu planı kontrolü
- Uygulama sürümlerinin ileri–geri uyumluluk testi
- Yedek ve geri yükleme yolunun teyidi
Yayın anı ve sonrası
- Hata oranı, gecikme metrikleri, kuyruk derinliği
- Replikasyon gecikmesi ve disk kullanımı
- İş kritik akışların duman testi (sipariş, ödeme, giriş vb.)
- Abort ve rollback tetik koşulları
Küçük ekiplerde bile yazılı bir kontrol listesi, “kim neyi izliyor” belirsizliğini azaltır. Yazılım geliştirme sürecinde migrasyon adımlarını kod incelemesi ve release notlarıyla birlikte yönetmek, operasyonel sürprizi düşürür.
Sıkça Sorulan Sorular
Sıfır kesinti migrasyon her zaman mümkün mü?
Her değişiklikte mutlak sıfır etki hedefi gerçekçi olmayabilir. Özellikle büyük veri dönüşümleri ve kısıt değişikliklerinde düşük etkili, aşamalı geçiş daha yönetilebilir bir hedeftir.
Eski ve yeni şema aynı anda nasıl çalışır?
Expand–contract yaklaşımında şema önce genişletilir, uygulama geçici olarak her iki yapıyı da destekler, veri doldurulur ve doğrulanır, ardından eski yapı daraltılır.
Rollback ne zaman devreye alınmalı?
Önceden tanımlı metrik eşikleri aşıldığında: hata oranında anlamlı yükseliş, kabul edilemez gecikme veya veri tutarsızlığı sinyali. Karar yetkisi ve iletişim kanalı da planda yazılı olmalıdır.
Backfill neden kritik?
Yalnızca yeni yazılan kayıtları dönüştürmek yetmez. Geçmiş veri uyumsuz kalırsa raporlar, arama ve arka plan işleri bozulabilir. Backfill, geçişin görünmez ama zorunlu parçasıdır.
Küçük ekipler bu planı sadeleştirebilir mi?
Evet. Envanter, geri dönüş kararı, aşamalı şema ve temel izleme metrikleri korunarak adımlar birleştirilebilir. Sadeleştirme, geri dönüş ve tutarlılık kontrollerini tamamen silmek anlamına gelmemelidir.
Veritabanı migrasyonu planlama işi, script yazmaktan çok riski parçalara bölmek, uyumluluk penceresi açmak ve ölçülebilir geri dönüş yolu bırakmaktır. Canlı trafik altında güvenli geçiş istiyorsanız, her adımı “ileri–doğrula–geri al” üçlüsüyle tasarlayın.
Özel yazılım veya mevcut sisteminizde kontrollü migrasyon planına ihtiyaç duyuyorsanız, KepezWeb ekibiyle kapsamı netleştirmek için teklif al sayfasından bize ulaşabilirsiniz. İhtiyacınıza uygun teknik adımları birlikte sadeleştiririz.
