- 01CDC, full load sonrasında oluşan değişiklikleri hedefe taşıyarak cutover anındaki veri farkını küçültür; sıfır kesinti garantisi vermez.
- 02Cutover kararı task durumuna değil replication lag, backlog, validation ve uygulama smoke test sonuçlarına göre verilmelidir.
- 03Write freeze sırasında yalnız web trafiği değil cron, queue consumer, worker ve entegrasyon gibi tüm writer'lar kontrol edilmelidir.
- 04Row count tek başına yeterli doğrulama değildir; checksum/hash, field-level, referential integrity ve business transaction testleri birlikte uygulanmalıdır.
- 05Rollback planı target'a yeni yazma başladıktan sonra verinin source'a nasıl geri taşınacağını da açıklamalıdır; yalnız connection string'i geri çevirmek yeterli olmayabilir.
Kısaca
CDC tabanlı database cutover'ın amacı production veritabanını uzun süre kapatmak değil, ilk veri kopyasını önceden tamamlayıp son değişiklikleri kontrollü biçimde hedefe yetiştirmektir. Sağlıklı akış; full load, sürekli değişiklik replikasyonu, lag takibi, yazma durdurma penceresi, final doğrulama, connection switch ve rollback kriterlerinden oluşur.
Dynamis Teknoloji'de cutover planını "gece taşı ve bakarız" yaklaşımıyla değil, ölçülmüş replication throughput, prova cutover ve önceden yazılmış başarı/geri dönüş kriterleri ile hazırlarız. CDC kesintiyi azaltabilir; ancak tek başına "zero downtime" garantisi değildir.
CDC nedir ve migration'da ne işe yarar?
Change Data Capture, kaynak veritabanında gerçekleşen insert, update ve delete değişikliklerini takip ederek hedef sisteme aktarmayı sağlayan yaklaşımdır.
Migration açısından CDC'nin değeri şudur:
- İlk full load günler veya saatler önce tamamlanabilir.
- Kaynak production çalışmaya devam eder.
- Full load sonrasında oluşan değişiklikler hedefe akar.
- Cutover anında yalnız kalan küçük fark kapatılır.
- Uygulama hedefe yönlendirilir.
Bu sayede büyük veri setlerinde cutover penceresi veri boyutundan ziyade replication lag + doğrulama + connection switch süresine yaklaşır.
Ancak CDC'nin sağlıklı çalışması için kaynak motor, transaction log/binlog/WAL yapısı, network, hedef yazma kapasitesi ve seçilen migration aracının birlikte doğrulanması gerekir.
CDC ile zero-downtime migration mümkün mü?
Bazı uygulamalarda kullanıcı tarafından hissedilen kesinti çok düşük seviyeye indirilebilir. Ancak "zero downtime" ifadesi dikkatli kullanılmalıdır.
Final cutover sırasında çoğu production sistemde en az şu işlemler gerekir:
- yeni yazmaları durdurma veya kontrollü hale getirme,
- CDC backlog'unun kapanmasını bekleme,
- son veri doğrulamasını çalışma,
- connection string / secret / DNS değiştirme,
- application instance'larını hedefe bağlama,
- kritik transaction testleri,
- rollback karar penceresi.
Bu nedenle hedef sıfır kesinti sözü vermek değil, iş etkisini ölçülmüş ve kontrollü bir pencereye indirmek olmalıdır.
Full load ve CDC neden birlikte kullanılır?
CDC tek başına geçmişteki bütün veriyi taşımak için ideal yöntem değildir.
Yaygın desen:
Faz 1 — Full load
Kaynak veritabanındaki mevcut veri hedefe kopyalanır.
Faz 2 — Ongoing replication
Full load sırasında ve sonrasında kaynakta oluşan değişiklikler CDC ile hedefe uygulanır.
Faz 3 — Cutover
Kaynak yazma trafiği kısa süre durdurulur, kalan change backlog kapatılır, veri doğrulanır ve uygulama hedefe yönlendirilir.
AWS Database Migration Service gibi araçlar full load + ongoing replication modelini destekler. Aynı mantık farklı migration araçlarında da kullanılabilir.
Cutover'ın gerçek kritik metriği: replication lag
CDC task'ının "running" olması hedefin gerçekten güncel olduğu anlamına gelmez.
İzlenmesi gereken temel metrikler:
- source-to-replication lag
- replication-to-target lag
- source transaction rate
- target apply throughput
- error/retry sayısı
- failed table veya object
- network latency
- CPU/memory/I/O saturation
- queue/backlog büyüklüğü
Cutover öncesi en önemli soru:
Kaynakta yeni yazmaları durdurduğumuzda backlog ne kadar sürede sıfıra iner?
Bu süre prova cutover ile ölçülmelidir.
Replication lag için tek bir doğru eşik var mı?
Hayır.
Örneğin:
- ödeme sistemi,
- raporlama veritabanı,
- internal CRM,
- düşük yazma hacimli arşiv sistemi
aynı RPO ve downtime toleransına sahip değildir.
Cutover kriteri şu değişkenlere göre tanımlanmalıdır:
- kabul edilebilir RPO
- kabul edilebilir maintenance window
- saniyedeki transaction sayısı
- hedef apply kapasitesi
- business criticality
- rollback süresi
Örnek kriter:
Write freeze başladıktan sonra replication lag 60 saniye içinde sıfıra inmeli; validation en fazla 10 dakika sürmeli.
Bu yalnız örnektir. Gerçek eşik proje ölçümleriyle belirlenmelidir.
Cutover öncesi readiness checklist
Production cutover onayı verilmeden önce en az şu alanlar yeşil olmalıdır.
Kaynak
- Backup başarılı
- Transaction log/WAL/binlog yeterli retention'a sahip
- CDC capture aktif
- Schema change freeze tanımlı
- Yeni deployment freeze zamanı belli
- Uygulama owner hazır
Hedef
- Schema tamam
- User/role hazır
- Index'ler tanımlı
- Sequence/identity değerleri doğrulanmış
- Storage kapasitesi yeterli
- Monitoring açık
- Backup politikası aktif
- Connection limit ve timeout değerleri hazır
Replikasyon
- Full load tamamlandı
- Failed table yok
- CDC aktif
- Lag trendi stabil
- Retry/error alarmı açık
- Large object davranışı test edildi
Uygulama
- Yeni connection string hazır
- Secret/config rollout planı hazır
- Readiness endpoint test edildi
- Feature flag veya maintenance mode hazır
- Kritik transaction testleri hazır
Operasyon
- Cutover owner belli
- Rollback owner belli
- War room / communication channel hazır
- Go/no-go zamanı belli
- Max cutover süresi belli
Schema freeze neden önemlidir?
CDC yalnız data değişikliklerini takip ediyor olabilir; her migration aracı DDL değişikliklerini aynı şekilde taşımaz.
Cutover'a yakın dönemde:
- yeni kolon,
- drop/rename,
- index değişikliği,
- procedure değişikliği,
- trigger değişikliği
yapılırsa source ve target şema drift'i oluşabilir.
Bu nedenle production migration için schema freeze tarihi belirlemek güçlü pratiktir.
Eğer değişiklik zorunluysa:
- değişiklik migration ekibine bildirilir,
- hedef şemaya uygulanır,
- CDC compatibility doğrulanır,
- tekrar validation yapılır.
Cutover provası nasıl yapılır?
Prova cutover production trafiğini gerçek hedefe almak zorunda değildir.
Ama şu adımlar gerçekçi biçimde ölçülmelidir:
- Full load süresi
- CDC throughput
- Normal peak yazma altında lag
- Write freeze sonrası backlog kapanma süresi
- Validation süresi
- Config/connection switch süresi
- Application restart veya rollout süresi
- Kritik transaction testleri
- Rollback süresi
Bu ölçüm maintenance window tahminini ciddi biçimde iyileştirir.
Cutover günü örnek akış
T-60 dakika
- Değişiklik freeze başlar
- Son sağlık kontrolleri yapılır
- CDC error/lag dashboard'u açılır
- Hedef backup/restore readiness doğrulanır
T-15 dakika
- Kullanıcı iletişimi gerekiyorsa yapılır
- Final go/no-go toplantısı yapılır
- Kaynak ve hedef state kaydedilir
T0 — Write freeze
- Uygulama maintenance/read-only moda alınır
- Yeni yazma oluşturulması durdurulur
- Background job ve queue consumer'lar kontrol edilir
T+1...n — Catch-up
- CDC backlog kapanması beklenir
- Replication lag sıfıra veya kabul edilen sınıra gelir
Final validation
- Row count
- checksum/hash
- kritik tablo karşılaştırmaları
- identity/sequence
- referential integrity
çalıştırılır.
Connection switch
- Secret / connection string / DNS değiştirilir
- Application hedef veritabanına bağlanır
Smoke test
- Login
- kayıt oluşturma
- güncelleme
- kritik rapor
- ödeme/sipariş gibi ana iş akışları
test edilir.
Go / rollback
Önceden yazılmış kriterlere göre karar verilir.
Queue ve background worker'lar neden unutulmamalı?
Web uygulamasını maintenance mode'a almak tüm yazmaları durdurmayabilir.
Ayrıca şu bileşenler yazma yapabilir:
- background worker
- cron
- ETL
- integration service
- message queue consumer
- scheduled report
- webhook processor
- batch job
Write freeze gerçekten "write freeze" olacaksa bütün writer'ların envanteri çıkarılmalıdır.
Connection string değişikliği nasıl yönetilmeli?
Connection bilgisini doğrudan production code'a gömmek yerine:
- secret manager,
- environment variable,
- configuration service,
- deployment config
üzerinden yönetmek cutover'ı kolaylaştırır.
Ayrıca connection pool'ların eski bağlantıları ne kadar süre tuttuğu önemlidir.
Hedefe geçtikten sonra bazı application instance'ları eski connection'ı kullanmaya devam ederse split-write riski doğabilir.
Bu nedenle rollout sırasında:
- eski instance'lar drain edilir,
- connection pool kapatılır,
- yeni config ile yeniden başlatılır.
DNS ile cutover yapılabilir mi?
Bazı mimarilerde evet; ancak database endpoint değişikliğini yalnız DNS üzerinden çözmek her zaman ideal değildir.
Dikkat edilmesi gerekenler:
- DNS TTL
- client-side DNS cache
- JVM/.NET DNS davranışı
- connection pool
- driver endpoint cache
Bu nedenle DNS cutover kullanılıyorsa gerçek client davranışı staging'de test edilmelidir.
Veri doğrulama yalnız row count değildir
Row count iyi bir ilk kontroldür ama yeterli değildir.
Örneğin hem kaynakta hem hedefte 10 milyon satır olabilir; bazı kolon değerleri yanlış dönüşmüş olabilir.
Katmanlı validation yaklaşımı:
1. Row count
Table bazında hızlı fark kontrolü.
2. Checksum / hash
Deterministik kolon setlerinden hash üretip karşılaştırma.
3. Field-level sampling
Kritik alanları örnekleyerek comparison.
4. Referential integrity
Orphan kayıt ve FK ilişkileri.
5. Business-level validation
Gerçek iş kuralları.
Örnek:
- toplam bakiye
- günlük sipariş sayısı
- invoice toplamı
- aktif kullanıcı sayısı
6. Application transaction
Gerçek write/read akışları.
Bir sonraki içerik olan CDC ile veri doğrulama rehberinde bu katmanı ayrıntılı ele alacağız.
Heterojen migration'da validation neden daha kritik?
SQL Server → PostgreSQL gibi motor değişimlerinde:
- veri tipi,
- timezone,
- collation,
- numeric precision,
- NULL/default,
- generated/computed field
davranışı farklı olabilir.
Bu nedenle "CDC error vermedi" ifadesi veri semantiğinin doğru taşındığını kanıtlamaz.
SQL Server'dan PostgreSQL'e geçiş rehberi hangi nesnelerin ve özelliklerin ayrıca uyarlanması gerektiğini açıklar.
Rollback planı cutover'dan önce nasıl yazılmalı?
Rollback planında dört soru net olmalıdır.
1. Eski kaynak ne kadar süre açık kalacak?
Rollback window tanımlanmalıdır.
2. Hedefe yeni yazma başladıktan sonra ne olacak?
Bu en kritik sorudur.
Cutover sonrası hedefte yeni veri oluşmuşsa eski kaynağa yalnız connection geri çevirerek dönmek veri kaybına yol açabilir.
Olası stratejiler:
- çok kısa observation window
- target → source reverse replication
- write discard kararı
- manual reconciliation
Proje gereksinimine göre önceden seçilmelidir.
3. Rollback trigger nedir?
Örnek:
- kritik transaction başarısız
- veri validation farkı
- p95 latency eşiği
- error rate
- target stability problemi
4. Rollback ne kadar sürer?
Prova sırasında ölçülmelidir.
Dual-write neden risklidir?
Migration sırasında hem source hem target'a uygulama seviyesinde eş zamanlı yazmak cazip görünebilir.
Ancak:
- partial failure
- retry
- ordering
- transaction boundary
- idempotency
- conflict resolution
problemleri yaratır.
Uygulama zaten dual-write için tasarlanmamışsa cutover gecesi bu modeli eklemek risklidir.
CDC genellikle daha kontrollü bir source-of-truth modeli sağlar.
Sequence ve identity neden final cutover'da tekrar kontrol edilir?
Veri kopyalandığında hedef sequence otomatik olarak doğru noktaya gelmeyebilir.
Örnek:
- target tabloda max ID = 5,000,000
- sequence next = 1,000
İlk yeni insert duplicate key hatası verir.
Bu nedenle cutover öncesi:
- max key
- sequence value
- identity state
karşılaştırılmalıdır.
Trigger'lar migration sırasında açık mı olmalı?
Her zaman değil.
Target trigger'lar CDC'nin uyguladığı satırlar üzerinde tekrar business logic çalıştırırsa:
- duplicate side effect
- audit duplication
- beklenmeyen update
- performans problemi
oluşabilir.
Bu yüzden target trigger davranışı migration planında açıkça belirlenmelidir:
- geçici disable,
- condition,
- migration session bypass,
- cutover sonrası enable.
Foreign key ve index'ler full load'u yavaşlatabilir mi?
Evet.
Büyük veri yüklerinde:
- foreign key check
- secondary index maintenance
- trigger
- constraint
yükleme throughput'unu düşürebilir.
Bazı migration stratejilerinde secondary index'ler full load sonrası oluşturulur.
Ancak bunu körlemesine yapmayın:
- production read performansı,
- CDC apply,
- constraint doğrulaması
birlikte değerlendirilmelidir.
CDC retention neden kritik?
Kaynak transaction log veya change log migration task'ının okuyabileceği süreden önce temizlenirse replikasyon kopabilir.
Bu nedenle:
- source retention
- migration tool checkpoint
- outage senaryosu
- replication restart süresi
birlikte planlanmalıdır.
Migration 6 saat durursa kaynak log hâlâ gerekli değişiklikleri tutuyor mu?
Bu soru cutover'dan önce cevaplanmalıdır.
Production cutover başarı kriterleri
Cutover tamamlandı demek application'ın açılması değildir.
Örnek başarı kriterleri:
- CDC backlog = 0
- validation farkı = 0 veya önceden kabul edilen istisnalar
- kritik transaction testleri başarılı
- application error rate normal
- p95 latency kabul edilen aralıkta
- backup ilk cycle başarılı
- monitoring aktif
- source write kapalı
- target write doğrulandı
Kriterler measurable olmalıdır.
Dynamis'te database cutover yaklaşımı
Dynamis'in Database Migration hizmetinde cutover tarihini ilk görüşmede sabitlemek yerine önce ölçüm yapıyoruz.
Discovery sırasında:
- source engine/version
- data size
- write rate
- transaction pattern
- network throughput
- acceptable RPO/RTO
- application dependency
- job/worker inventory
- schema change frequency
çıkarılır.
Sonra:
- pilot full load,
- CDC throughput testi,
- validation denemesi,
- prova cutover,
- rollback provası
ile gerçek maintenance window oluşturulur.
Amaç "zero downtime" pazarlamak değil, ölçülmüş downtime, veri bütünlüğü ve geri dönüş opsiyonu ile güvenli production geçişi sağlamaktır.
Sık yapılan hatalar
CDC task running diye hedefin güncel olduğunu sanmak: Lag ve backlog'u ölçün.
Yalnız web uygulamasını maintenance mode'a almak: Worker, cron, queue ve integration writer'larını da durdurun.
Row count eşleşti diye validation tamam demek: Checksum, field-level ve business transaction kontrollerini ekleyin.
Connection pool davranışını unutmak: Eski bağlantılar source'a yazmaya devam edebilir.
Rollback planını connection string geri alma sanmak: Target'a yeni yazma başladıysa veri reconciliation gerekir.
Schema değişikliklerine cutover haftasında devam etmek: Drift riskini artırır.
Prova cutover yapmamak: Gerçek lag, validation ve rollback süreleri bilinmez kalır.
Sırada ne var
- SQL Server'dan PostgreSQL'e geçiş: heterojen migration'da schema ve code farklarını inceleyin.
- Cloud migration sırasında downtime nasıl minimuma indirilir?: database dışındaki workload'larda kontrollü cutover yaklaşımını inceleyin.
- Cloud Migration Checklist: production cutover öncesi genel hazırlığı doğrulayın.
- Bulut göçü sırası: migration wave planı: application ve database bağımlılıklarını aynı wave içinde planlayın.
- Database migration hizmeti: kendi database cutover planınızı değerlendirin.
Kaynaklar
Kaynaklar
- 1.Creating AWS DMS replication tasksAmazon Web Services · 2026-09-25
- 2.AWS DMS data validationAmazon Web Services · 2026-09-25
- 3.Monitoring AWS DMS tasksAmazon Web Services · 2026-09-25
- 4.About Change Data Capture (SQL Server)Microsoft Learn · 2026-09-25
- 5.PostgreSQL Logical ReplicationPostgreSQL Global Development Group · 2026-09-25
Sık sorulan sorular
CDC kullanınca database migration sıfır kesintiyle yapılabilir mi?
Hayır, CDC tek başına sıfır kesinti garantisi vermez. CDC kaynak veritabanındaki değişiklikleri hedefe sürekli taşıyarak cutover anındaki veri farkını küçültür. Final geçişte yazma trafiğini kısa süre durdurmak, son değişikliklerin hedefe ulaştığını doğrulamak, connection bilgisini değiştirmek ve kritik transaction testlerini çalıştırmak gerekebilir. Kesinti hedefi; kaynak motor, hedef motor, yazma yoğunluğu, replication lag ve uygulama mimarisine göre belirlenmelidir.
Database cutover sırasında replication lag kaç olmalı?
Tek bir evrensel eşik yoktur. Cutover kriteri kaynak yazma hızı, hedefin uygulama kapasitesi, kabul edilebilir RPO ve iş etkisine göre belirlenir. Pratikte ekip son yazma penceresinde kaynakta yeni değişiklik oluşturmayı durdurur, CDC backlog'unun sıfıra veya önceden tanımlanan güvenli sınıra gelmesini bekler ve ardından veri doğrulamasını çalıştırır. Eşik discovery ve prova cutover sırasında ölçülmelidir.
Database migration rollback planı nasıl hazırlanır?
Rollback planı cutover'dan önce yazılmalıdır. Eski veritabanının hangi süre boyunca kullanılabilir tutulacağı, geri dönüş durumunda yeni hedefte oluşan yazmaların nasıl ele alınacağı, DNS/connection string değişiminin nasıl geri alınacağı ve rollback tetikleyicileri açıkça tanımlanmalıdır. Veri iki tarafta da değişmişse basit connection rollback'i yeterli olmayabilir; bu nedenle final cutover sonrasında çift yönlü yazma veya kontrolsüz dual-write başlatılmamalıdır.
Database cutover öncesi hangi veriler doğrulanmalı?
En az row count, kritik tablo checksum/hash karşılaştırması, alan bazlı örnekleme, referential integrity ve kritik iş transaction'ları doğrulanmalıdır. Ayrıca sequence/identity değerleri, timezone davranışı, NULL/default farkları, trigger sonuçları ve en ağır sorguların performansı kontrol edilmelidir. Heterojen migration'larda yalnız satır sayısı eşleşmesi veri doğruluğunu kanıtlamaz.
Cutover provası yapmak gerekli mi?
Production etkisi yüksek migration projelerinde prova cutover güçlü biçimde önerilir. Prova; full load süresini, CDC throughput ve lag değerlerini, validation süresini, connection switch adımlarını, rollback süresini ve ekipler arası handoff'u ölçer. Bu veriler gerçek bakım penceresini tahmin etmek ve kabul kriterlerini netleştirmek için kullanılır.