Veritabanı Taşıma (Migration) Süreçlerinde Sıfır Kesinti Taktikleri

Canlı bir veritabanını taşımak, yalnızca veriyi bir sunucudan diğerine kopyalamak değildir. Gerçek zorluk, kullanıcılar işlem yapmaya devam ederken eski ve yeni sistem arasında veri bütünlüğünü korumaktır. On yıllık backend ve database çalışmalarında gördüğüm en büyük hata, migration gününü tek bir büyük cutover anı gibi planlamaktır. Veritabanı Taşıma (Migration) Süreçlerinde Sıfır Kesinti Taktikleri yaklaşımında asıl hedef, riskli değişiklikleri küçük, gözlemlenebilir ve geri döndürülebilir adımlara bölmektir. Bu rehberde veritabanı migration işlemi sıfır kesinti ile nasıl yapılır, zero downtime database migration stratejileri nelerdir ve database migration sürecinde blue green deployment CDC ve rollback stratejileri nasıl birlikte yönetilir sorularını production bakışıyla ele alacağım.

Veritabanı Migration Nedir?

Veritabanı migration, veri yapısının, verinin kendisinin veya database çalışma ortamının kontrollü biçimde değiştirilmesidir. Bu değişiklik aynı database engine içinde olabileceği gibi farklı bir engine veya cloud platformuna geçiş şeklinde de gerçekleşebilir. Migration yalnızca teknik taşıma değil, application compatibility, veri doğrulama ve operasyon sürecidir. Başarılı migration kaynak sistem kapanmadan önce hedef sistemin gerçek trafik altında doğrulandığı bir geçiş modeli kullanır. Bu nedenle migration planı schema, data, application ve infrastructure katmanlarını birlikte ele almalıdır.

Database Migration Kavramı

Database migration bir veri sisteminin mevcut durumdan hedef duruma kontrollü geçişidir. Hedef yeni schema, yeni sunucu, yeni database engine veya yeni cloud ortamı olabilir. Migration boyunca veri kaybı ve kullanıcı hatası oluşmaması hedeflenir. Production sisteminde rollback yolu da migration kadar önemlidir. Başarı yalnızca verinin hedefe ulaşmasıyla değil, uygulamanın hedef üzerinde doğru çalışmasıyla ölçülür.

Schema Migration Nedir?

Schema migration tablo, kolon, index ve constraint gibi database yapılarının değiştirilmesidir. Yeni kolon eklemek basit görünebilir ancak büyük tabloda lock etkisi yaratabilir. Breaking schema değişiklikleri rolling deployment ile uyumsuzluk oluşturabilir. Expand-and-contract bu riski küçük aşamalara böler. Schema migration her zaman gerçek production veri hacmine yakın ortamda test edilmelidir.

Data Migration Nedir?

Data migration mevcut kayıtların yeni tablo, kolon veya database sistemine taşınmasıdır. Historical data genellikle batch veya full load yöntemiyle aktarılır. Migration devam ederken oluşan yeni write işlemleri ayrıca yakalanmalıdır. CDC veya kontrollü dual write bu boşluğu kapatabilir. Veri taşıma tamamlandıktan sonra source ve target mutlaka karşılaştırılmalıdır.

Database Engine Migration Nedir?

Database engine migration PostgreSQL, MySQL veya başka bir engine arasında geçiş anlamına gelir. SQL syntax, veri tipleri ve transaction davranışları farklı olabilir. Stored procedure ve trigger gibi database içi logic ayrıca dönüştürülmelidir. Performance profili hedef engine üzerinde yeniden ölçülmelidir. Heterogeneous migration bu nedenle yalnızca data copy olarak değerlendirilmemelidir.

Cloud Database Migration Nedir?

Cloud database migration on-prem veya mevcut cloud ortamındaki database'in yeni managed veya self-managed hedefe taşınmasıdır. Network bağlantısı migration throughput'unu doğrudan etkiler. Security group, encryption ve credential planı önceden hazırlanmalıdır. Cloud target'ın connection, IOPS ve storage kapasitesi source workload'u karşılamalıdır. Cutover günü ilk kez performance testi yapmak ciddi risktir.

Version Upgrade ile Migration Arasındaki Fark

Version upgrade aynı database ürününün daha yeni sürümüne geçiştir. Migration ise çoğu zaman daha geniş topology veya engine değişikliğini kapsar. Major version upgrade data formatı veya SQL davranışını değiştirebilir. Blue-green yöntem version upgrade için de kullanılabilir. Her upgrade küçük görünse bile rollback ve compatibility planına ihtiyaç duyar.

Sıfır Kesintili Veritabanı Migration Nedir?

Sıfır kesintili migration kullanıcı trafiğini planlı olarak durdurmadan database değişikliğini tamamlamayı hedefler. Kaynak ve hedef sistem bir süre birlikte çalışır. Veri sürekli senkronize edilir ve trafik kademeli olarak yeni sisteme alınır. Bu yaklaşım yalnızca teknik replication değil, application compatibility ve rollback tasarımı gerektirir. Özellikle yüksek trafikli sistemlerde cutover yerine aşamalı geçiş düşünmek daha güvenlidir.

Zero Downtime Ne Anlama Gelir?

Zero downtime kullanıcıların migration nedeniyle bilinçli servis kesintisi yaşamaması anlamına gelir. Sistem bazı anlarda küçük latency artışları yaşayabilir. Başarı kullanıcı işlemlerinin kabul edilebilir SLO içinde devam etmesiyle ölçülür. Database katmanında kısa topology değişimi kullanıcıya hata olarak yansımamalıdır. Retry ve connection yönetimi bu hedefin önemli parçasıdır.

Zero Planned Downtime ile Mutlak Sıfır Kesinti Arasındaki Fark

Zero planned downtime bakım penceresi açmadan migration yapmayı hedefler. Mutlak sıfır hata ise dağıtık sistemlerde gerçekçi olmayan daha katı bir beklenti olabilir. Network veya client reconnect nedeniyle kısa transient hatalar her zaman ihtimal dahilindedir. Burada önemli olan kullanıcı etkisini SLO altında tutmaktır. Migration hedefi teknik slogan yerine ölçülebilir kriterlerle tanımlanmalıdır.

Kullanıcı Tarafından Görülen Kesinti Nasıl Ölçülür?

HTTP hata oranı, transaction success ve request latency kullanıcı etkisini gösterir. Database failover süresine tek başına bakmak yeterli değildir. Client connection pool yeniden bağlanana kadar uygulama hata üretebilir. Business transaction metriği bu nedenle önemlidir. Checkout veya login başarısının düşmesi gerçek kesinti sinyalidir.

Minimal Downtime ile Zero Downtime Arasındaki Fark

Minimal downtime kısa maintenance penceresini kabul eder. Zero downtime ise kullanıcı trafiği sürerken geçiş yapmayı amaçlar. Küçük sistemlerde birkaç dakikalık maintenance daha düşük riskli olabilir. Kritik sistemlerde bu süre kabul edilmeyebilir. Mimari hedef business SLA üzerinden belirlenmelidir.

Veritabanı Taşıma İşlemleri Neden Kesintiye Yol Açar?

Migration sırasında kesinti çoğu zaman veri kopyalama işleminden değil, lock, application uyumsuzluğu ve cutover davranışından kaynaklanır. Büyük DDL işlemleri tabloyu bloke edebilir. CDC geride kalırsa hedef database güncel olmayabilir. Connection pool eski endpoint'i kullanmaya devam edebilir. Bu riskler migration öncesinde tek tek ölçülmelidir.

DDL Locks

Bazı ALTER TABLE işlemleri güçlü lock gerektirir. Hot table üzerindeki lock request trafiğini bekletebilir. Lock süresi table size ve engine davranışına bağlıdır. Lock seviyesini staging ortamında ölçmek gerekir. Timeout olmadan production DDL çalıştırmak risklidir.

Long-Running Transactions

Uzun transaction schema değişikliğinin gerekli lock'u almasını engelleyebilir. Migration query beklerken yeni request'ler kuyrukta birikebilir. Bu durum kısa DDL'i uzun outage'a çevirebilir. Cutover öncesi açık transaction'lar kontrol edilmelidir. Transaction timeout politikası production sağlığına katkı sağlar.

Table Rewrite

Bazı schema değişiklikleri tüm tablonun fiziksel olarak yeniden yazılmasını gerektirir. Büyük tabloda bu işlem uzun sürebilir. Disk I/O ve transaction log üretimi ciddi biçimde artabilir. Engine sürümüne göre davranış değişebilir. Production öncesi dry-run ile gerçek süre ölçülmelidir.

Index Oluşturma

Normal index build bazı database sistemlerinde write trafiğini bloke edebilir. Online veya concurrent seçenekler bu etkiyi azaltabilir. Buna rağmen CPU, memory ve I/O kullanımı artar. Index build replication lag oluşturabilir. Migration planı performans etkisini de kapsamalıdır.

Constraint Validation

Yeni constraint existing data üzerinde doğrulama gerektirebilir. Büyük tablo taraması I/O ve lock baskısı oluşturabilir. Constraint önce düşük etkili şekilde eklenip daha sonra validate edilebilir. Invalid kayıtlar önceden temizlenmelidir. Validation migration penceresinden bağımsız yürütülebilir.

Büyük Backfill İşlemleri

Milyonlarca satırı tek transaction içinde güncellemek database'i zorlayabilir. WAL veya binlog hacmi hızla büyür. Replica lag ciddi seviyeye çıkabilir. Küçük batch ve throttle daha güvenlidir. Backfill her zaman resumable ve idempotent olmalıdır.

Replication Lag

Target database source değişikliklerini gecikmeli alabilir. Cutover lag sıfırlanmadan yapılırsa son kayıtlar kaybolmuş gibi görünür. Büyük transaction veya yetersiz target kapasitesi lag'i artırır. Lag sürekli ölçülmelidir. Cutover için maksimum kabul edilebilir eşik önceden tanımlanmalıdır.

Connection Pool Saturation

Migration sırasında source ve target'a eş zamanlı connection açılması toplam connection sayısını yükseltebilir. Shadow read ve dual write bu baskıyı artırır. Pool limiti aşılırsa normal kullanıcı request'leri bekler. Migration connection'ları ayrı budget kullanmalıdır. Target database max connection kapasitesi önceden test edilmelidir.

Application-Schema Uyumsuzluğu

Yeni application yalnızca yeni schema'yı destekliyorsa rolling deployment sırasında eski instance'lar bozulabilir. Eski kodun kullandığı kolonu aynı deployment'ta silmek buna örnektir. Compatibility window bu riski azaltır. Application ve schema değişikliği ayrı adımlara bölünmelidir. Her sürüm geçici süre iki schema durumuyla da çalışabilmelidir.

Cutover Sırasındaki Connection Storm

Binlerce application instance aynı anda yeni database'e bağlanırsa target kısa süreli aşırı yük alabilir. Authentication ve connection establishment CPU tüketir. Pool'ların aynı anda yenilenmesi latency spike oluşturur. Jitter ve kontrollü drain kullanılabilir. Target cutover load'u önceden test edilmelidir.

Migration Öncesinde Başarı Kriterleri Nasıl Belirlenir?

Migration başarısı "çalıştı" veya "çalışmadı" şeklinde tanımlanmamalıdır. Maksimum downtime, error rate, latency ve data consistency için sayısal hedefler belirlenmelidir. Rollback kararının hangi metrikte verileceği önceden yazılmalıdır. Cutover sırasında tartışma yerine bu kriterler kullanılmalıdır. Ölçülemeyen migration hedefi operasyon ekibini gereksiz belirsizliğe iter.

Maksimum Kabul Edilebilir Kesinti

Business ekibi kullanıcı açısından kabul edilebilir maksimum kesinti süresini tanımlar. Bu değer saniye veya dakika olabilir. Teknik ekip topology ve cutover tasarımını buna göre hazırlar. Hedef sıfıra yakınsa automated failover gerekir. Uygulama tarafındaki reconnect süresi de bu bütçeye dahildir.

Maksimum Replication Lag

Cutover öncesi target source'a yeterince yakın olmalıdır. Kabul edilen lag veri kaybı riskine göre belirlenir. Kritik sistemlerde birkaç saniye bile fazla olabilir. Lag sürekli düşmüyorsa cutover ertelenmelidir. Tek anlık değer yerine trend izlenmelidir.

Kabul Edilebilir Error Rate

Migration sırasında normal production baseline'dan ne kadar hata artışı kabul edileceği belirlenmelidir. HTTP 5xx ve database error ayrı izlenebilir. Belirli eşik rollback tetikleyebilir. Canary aşamasında daha katı eşik kullanılabilir. Error budget migration riskini sayısallaştırır.

P95 ve P99 Latency Eşikleri

Ortalama latency cutover problemini gizleyebilir. p95 ve p99 tail davranışını gösterir. Database değişimi connection veya query plan farkı nedeniyle tail'i artırabilir. Her traffic aşamasında eşikler kontrol edilmelidir. Limit aşılırsa trafik artırılmamalıdır.

Data Consistency Eşiği

Source ve target arasındaki mismatch oranı açıkça tanımlanmalıdır. Kritik tablolar için sıfır mismatch gerekebilir. Büyük analytics tablolarında belirli tolerans olabilir. Business aggregate değerleri ayrıca karşılaştırılmalıdır. Validation geçmeden writer switch yapılmamalıdır.

Rollback Süresi

Rollback teorik olarak mümkün olmakla kalmamalı, belirli sürede tamamlanabilmelidir. Feature flag saniyeler içinde route değiştirebilir. Data divergence oluşmuşsa rollback çok daha uzun sürer. Reverse CDC bu süreyi azaltabilir. Rollback RTO ayrıca test edilmelidir.

Migration Completion Criteria

Migration yalnızca write target'a geçtiğinde tamamlanmış sayılmamalıdır. Stability window başarıyla geçmelidir. Final reconciliation ve backup alınmalıdır. Source kullanımının sona erdiği doğrulanmalıdır. Decommission ayrı completion gate olmalıdır.

Migration Öncesi Mevcut Database Nasıl Analiz Edilir?

Migration başlamadan önce source database'in gerçek workload'u ayrıntılı biçimde anlaşılmalıdır. Boyut, read/write throughput, transaction rate ve lock davranışı ölçülmelidir. Stored procedure, trigger ve extension gibi görünmeyen bağımlılıklar envantere alınmalıdır. Sequence ve identity alanları özellikle cutover sonrası collision riski taşır. Bu analiz yapılmadan hazırlanan migration planı production'da sürpriz üretir.

Database Boyutu

Toplam data ve index boyutu migration süresini belirler. Backup ve WAL alanı ayrıca hesaplanmalıdır. Compression source ve target boyutunu değiştirebilir. Network throughput full load süresini etkiler. Growth rate de plana eklenmelidir.

Table Boyutları

En büyük tablolar migration'ın büyük kısmını oluşturur. Bu tablolar ayrı batch veya parallel stream ile taşınabilir. Hot table ve cold table ayrımı yapılmalıdır. Büyük tablo validation daha uzun sürer. Table bazlı migration süresi ölçülmelidir.

Write Throughput

Source saniyede ne kadar write üretiyor bilinmelidir. CDC target'ın bu hızı sürekli karşılaması gerekir. Full load sırasında write trafiği de devam eder. Target apply rate source write rate'in altında kalırsa lag kapanmaz. Peak saat değerleri kullanılmalıdır.

Read Throughput

Read QPS target sizing için önemlidir. Shadow read bir süre load'u ikiye katlayabilir. Query cache davranışı source ve target arasında farklı olabilir. Read cutover canary ile yapılmalıdır. p99 query latency karşılaştırılmalıdır.

Transaction Rate

Transaction sayısı log üretimini ve connection davranışını etkiler. Büyük ama seyrek transaction ile küçük ve yoğun transaction farklı risk taşır. Target concurrency test edilmelidir. Commit latency cutover sonrası değişebilir. Transaction size distribution ölçülmelidir.

Long-Running Queries

Uzun query migration DDL lock'larını geciktirebilir. Replica veya CDC snapshot davranışını etkileyebilir. Slow query listesi çıkarılmalıdır. Gerekirse migration öncesi query optimize edilir. Cutover sırasında ağır analytics workload durdurulabilir.

Lock Analizi

Hot tablolar üzerindeki lock pattern'i incelenmelidir. DDL'in hangi transaction'ları bekleyeceği test edilir. Deadlock ve lock wait history yararlıdır. lock_timeout güvenlik katmanı sağlar. Migration script sonsuza kadar lock beklememelidir.

Stored Procedures

Stored procedure business logic taşıyor olabilir. Hedef engine syntax veya behavior açısından farklı olabilir. Procedure envanteri çıkarılmalıdır. Unit ve integration test hazırlanmalıdır. Performance hedef sistemde yeniden ölçülmelidir.

Triggers

Trigger'lar görünmeyen write side effect oluşturabilir. CDC veya dual write sırasında duplicate işlem üretebilir. Target'ta aynı trigger'ın gerekli olup olmadığı belirlenmelidir. Migration tooling trigger'ları farklı ele alabilir. Cutover öncesi semantic validation yapılmalıdır.

Views

View'lar application query contract'ının parçası olabilir. Hedef schema değişince dependency kırılabilir. Materialized view ayrıca refresh gerektirebilir. View definition engine uyumluluğu test edilmelidir. Kullanılmayan view migration kapsamından çıkarılabilir.

Extensions

Database extension'ları migration'ın gizli bağımlılıklarıdır. Hedef platform aynı extension'ı desteklemeyebilir. Version farkları behavior değişikliğine neden olabilir. Alternatif çözüm migration öncesi hazırlanmalıdır. Extension kullanım sorguları envantere alınmalıdır.

Sequence ve Identity Alanları

Sequence değerleri data copy ile otomatik doğru seviyeye gelmeyebilir. Target sequence son ID'nin üzerinde olmalıdır. Dual write sırasında farklı ID üreticileri collision yaratabilir. Single writer prensibi korunmalıdır. Cutover öncesi sequence check zorunlu olmalıdır.

Homogeneous ve Heterogeneous Migration

Homogeneous migration aynı database engine ailesi içinde gerçekleşir. Heterogeneous migration farklı engine'ler arasında veri ve davranış dönüşümü gerektirir. Aynı engine migration genellikle schema ve SQL uyumluluğu açısından daha düşük risklidir. Farklı engine geçişinde type, function ve transaction behavior yeniden değerlendirilir. Bu nedenle test ve compatibility süresi daha uzun tutulmalıdır.

Homogeneous Migration

Homogeneous migration source ve target'ta aynı database engine'i kullanır. Replication ve backup araçları daha doğrudan kullanılabilir. Schema dönüşümü sınırlıdır. Sürüm farkı yine behavior değişikliği yaratabilir. Performance karşılaştırması yapılmalıdır.

PostgreSQL → PostgreSQL

PostgreSQL'den PostgreSQL'e migration logical replication veya managed migration araçlarıyla yapılabilir. Extension ve major version uyumluluğu kontrol edilmelidir. Sequence değerleri ayrıca doğrulanmalıdır. Replica veya CDC ile düşük kesintili cutover kurulabilir. Target query plan'ları kaynakla birebir aynı olmayabilir.

MySQL → MySQL

MySQL migration binlog tabanlı replication ile sürekli senkronize edilebilir. GTID cutover yönetimini kolaylaştırabilir. SQL mode ve collation farkları kontrol edilmelidir. Auto increment state target'ta doğrulanmalıdır. Version-specific DDL behavior test edilmelidir.

Heterogeneous Migration

Heterogeneous migration farklı database engine'leri arasında gerçekleşir. Schema conversion zorunlu hale gelir. Stored procedure ve function yeniden yazılabilir. Data type mapping dikkat ister. Application SQL compatibility kapsamlı test edilmelidir.

Oracle → PostgreSQL

Oracle ve PostgreSQL arasında veri tipi ve procedural language farkları bulunur. Sequence ve identity davranışı yeniden tasarlanabilir. Stored procedure conversion ayrı proje haline gelebilir. SQL semantics test edilmelidir. Performance tuning hedef engine'e göre tekrar yapılmalıdır.

MySQL → PostgreSQL

MySQL ve PostgreSQL type, collation ve SQL behavior açısından farklılık gösterebilir. Boolean ve timestamp gibi alanlar ayrıca kontrol edilmelidir. Auto increment sequence modeline dönüştürülebilir. Query syntax ve function kullanımı test edilmelidir. CDC tool desteği migration tasarımını etkiler.

SQL Server → PostgreSQL

SQL Server'a özgü data type ve T-SQL yapıları PostgreSQL'e dönüştürülmelidir. Identity ve sequence behavior kontrol edilmelidir. Stored procedure yeniden yazımı gerekebilir. Index ve query plan yaklaşımı değişebilir. Uygulama compatibility testleri geniş tutulmalıdır.

Heterogeneous Migration Neden Daha Risklidir?

Farklı engine'ler aynı SQL'i farklı yorumlayabilir. Veri tipi precision ve collation sonucu değişebilir. Trigger ve stored procedure davranışı birebir taşınmayabilir. Performance sorunları ancak gerçek workload altında görünür olabilir. Bu nedenle shadow read ve business validation daha önemli hale gelir.

Zero-Downtime Migration İçin Temel Stratejiler

Zero downtime migration tek bir teknikle sağlanmaz. Expand-and-contract schema compatibility sağlar, CDC veri senkronizasyonunu yürütür ve feature flag trafik kontrolünü mümkün kılar. Blue-green yaklaşımı source ile target'ı yan yana tutar. Shadow read doğruluk ve performansı kullanıcıyı etkilemeden test eder. Veritabanı taşımada expand contract dual write ve backfill nasıl uygulanır sorusunun cevabı bu yöntemleri doğru sırada birleştirmektir.

Expand-and-Contract

Breaking schema değişikliğini birden fazla deployment'a böler. Önce yeni yapı eklenir. Application iki yapı ile çalışabilir hale gelir. Veri taşındıktan ve trafik yeni yapıya geçtikten sonra eski alan kaldırılır. Rollback penceresi böylece uzun tutulur.

Change Data Capture

CDC transaction log üzerinden source değişikliklerini target'a taşır. Application code değişikliği gerektirmeden senkronizasyon sağlayabilir. Full load sonrası yeni write'ları yakalar. Lag sürekli ölçülmelidir. Cutover target source'a yetiştikten sonra yapılır.

Dual Write

Application aynı business write'ı source ve target'a gönderebilir. Veri iki sistemde güncel tutulur. Partial failure consistency riski yaratır. Idempotency ve reconciliation gerekir. Transactional outbox doğrudan çift yazıdan daha güvenli olabilir.

Blue-Green Database

Blue mevcut production database, green yeni hedef sistemdir. İki taraf geçiş boyunca senkron tutulur. Read trafiği kademeli green'e alınabilir. Writer en son taşınır. Blue rollback süresi boyunca korunur.

Replica Promotion

Aynı engine migration'da replica hedef database olarak hazırlanabilir. Replica source'a yetiştikten sonra promotion yapılır. Application yeni primary'ye yönlendirilir. Old primary read-only tutulabilir. Split-brain riskine karşı fencing gerekir.

Shadow Read

Kullanıcı cevabı source database'den almaya devam eder. Aynı read target üzerinde arka planda çalıştırılır. Sonuçlar karşılaştırılır. Mismatch ve latency ölçülür. Kullanıcı target hatasından etkilenmez.

Phased Cutover

Trafik bir anda yüzde yüz taşınmaz. Internal, yüzde bir, yüzde on ve daha yüksek oranlarla ilerlenebilir. Her aşamada quality gate kontrol edilir. Sorun çıkarsa önceki aşamaya dönülür. Bu yöntem blast radius'u sınırlar.

Feature Flag

Read ve write routing feature flag ile kontrol edilebilir. Tenant veya kullanıcı kohortu bazında açılabilir. Deployment yapmadan hızlı rollback sağlar. Flag state merkezi ve güvenilir olmalıdır. Database topology kararının kalıcı config'e dönüşmesi planlanmalıdır.

Expand-and-Contract Pattern Nedir?

Expand-and-contract schema değişikliğini backward-compatible aşamalara böler. İlk aşamada yeni schema öğeleri eski kodu bozmadan eklenir. Migrate aşamasında data ve application behavior yeni yapıya taşınır. Contract aşamasında artık kullanılmayan eski alanlar kaldırılır. Bu yaklaşım zero downtime schema migration için en güvenli temel modellerden biridir.

Expand

Yeni kolon, tablo veya index eklenir. Eski application version çalışmaya devam eder. Yeni yapı henüz zorunlu hale getirilmez. Breaking constraint sonraya bırakılır. Rollback kolaylığını korumak amaçlanır.

Migrate

Yeni application version deploy edilir. Gerekirse dual write başlatılır. Historical data backfill edilir. Read path kademeli yeni schema'ya taşınır. Validation sürekli devam eder.

Contract

Eski kolon veya table artık kullanılmadığı doğrulanır. Application eski alana yazmayı bırakır. Stability window geçirilir. Daha sonra destructive migration uygulanır. Bu adım point of no return'a yaklaşır.

Neden Breaking Değişiklikler Tek Deployment'ta Yapılmamalıdır?

Rolling deployment sırasında eski ve yeni application instance'lar aynı anda çalışabilir. Yeni schema yalnızca yeni kodla uyumluysa eski instance hata verir. Rollback de zorlaşır. Aşamalandırma compatibility window oluşturur. Production riskini tek değişiklikten birkaç küçük değişikliğe böler.

Expand Aşaması Nasıl Yapılır?

Expand aşaması mevcut application davranışını bozmadan yeni schema'yı production'a ekler. Kolonlar başlangıçta nullable bırakılabilir. Index mümkünse online veya concurrent yöntemle oluşturulur. Yeni constraint enforcement hemen aktif edilmez. Bu aşamanın amacı eski ve yeni application version'ların birlikte çalışmasına izin vermektir.

Yeni Kolon Eklemek

Yeni kolon mümkünse nullable veya güvenli default ile eklenir. Büyük table rewrite yaratacak default behavior test edilmelidir. Eski kod kolonu bilmeden çalışmaya devam eder. Yeni kod daha sonra bu alanı doldurur. Historical kayıtlar ayrı backfill job ile tamamlanır.

Yeni Tablo Eklemek

Yeni tablo mevcut query path'i etkilemeden oluşturulabilir. Index ve constraint'ler production load'a göre planlanır. Application başlangıçta tabloya yalnızca ek write yapabilir. Data validation tamamlandıktan sonra read source olarak kullanılabilir. Eski tablo bir süre korunur.

Yeni Index Eklemek

Index ekleme table lock etkisi açısından incelenmelidir. PostgreSQL concurrent veya MySQL online seçenekleri kullanılabilir. CPU ve I/O sınırı izlenir. Index build başarısızsa invalid artifact kontrol edilir. Query planner'ın gerçekten index'i kullandığı doğrulanmalıdır.

Yeni Constraint İçin Hazırlık

Constraint eklenmeden önce existing data uyumu kontrol edilir. Hatalı kayıtlar backfill veya cleanup ile düzeltilir. Enforcement önce yalnızca yeni write için uygulanabilir. Validation daha sonra çalıştırılabilir. Bu yöntem uzun table scan'in deployment'ı bloke etmesini önler.

Eski Application Version ile Uyumluluğu Korumak

Eski code yeni schema değişikliğinden habersiz çalışabilmelidir. Existing kolon hemen rename veya drop edilmemelidir. Yeni field optional tutulabilir. API contract ayrıca uyumlu olmalıdır. Rollback yapıldığında eski version tekrar sorunsuz başlamalıdır.

Compatibility Window Nedir?

Compatibility window eski ve yeni application version'larının aynı database schema üzerinde güvenli çalışabildiği geçiş dönemidir. Rolling deployment ve rollback için bu pencere gereklidir. Yeni schema eklenirken eski alanlar hemen kaldırılmaz. Pencere veri backfill ve doğrulama tamamlanana kadar açık tutulur. Contract değişiklikleri stability kanıtlandıktan sonra yapılır.

Eski ve Yeni Application Version'ların Birlikte Çalışması

Deployment sırasında tüm instance'lar aynı saniyede güncellenmez. Bazıları eski code ile request almaya devam eder. Schema iki version'ın ihtiyacını da karşılamalıdır. Dual read veya dual write geçici çözüm olabilir. Version mix süresi ölçülmelidir.

Backward Compatibility

Yeni schema eski application'ın beklediği alanları korur. Existing kolon drop edilmez. Constraint değişikliği eski write'ı reddetmemelidir. Default behavior dikkatle seçilir. Rollback olasılığı bu uyumluluğa dayanır.

Forward Compatibility

Eski schema state yeni code'un temel fonksiyonlarını bozmayacak şekilde düşünülmelidir. Yeni code optional field yokluğunu tolere edebilir. Migration henüz tamamlanmamış kayıtlara fallback uygulanabilir. Bu durum deploy sırasını daha esnek yapar. Her feature için gerekli olmayabilir.

Rolling Deployment ile Schema Uyumu

Rolling deployment instance'ları küçük gruplar halinde yeniler. Database schema bütün version'larla uyumlu olmalıdır. Breaking change deployment bitmeden yapılmamalıdır. Health check her batch sonrası kontrol edilir. Contract ayrı release olarak planlanmalıdır.

Compatibility Window Ne Zaman Kapatılmalıdır?

Tüm application instance'lar yeni version'a geçmelidir. Backfill tamamlanmış olmalıdır. Yeni read path istikrarlı çalışmalıdır. Eski field kullanım metric'i sıfıra inmelidir. Ancak bundan sonra destructive contract değişikliği güvenle yapılabilir.

Kolon Yeniden Adlandırma Sıfır Kesintiyle Nasıl Yapılır?

Kolonu doğrudan rename etmek eski application instance'larını anında bozabilir. Daha güvenli yöntem yeni kolon ekleyip bir süre iki alanı birlikte kullanmaktır. Historical data yeni kolona taşınır. Read path yeni kolona geçirildikten sonra eski write kapatılır. Eski kolon ancak stability window sonrasında kaldırılır.

Yeni Kolonu Eklemek

Yeni isimle ikinci kolon oluşturulur. Kolon başlangıçta nullable olabilir. Eski code eski field'ı kullanmaya devam eder. Yeni application her iki alanı bilir. Schema değişikliği backward-compatible kalır.

Dual Write

Yeni application aynı değeri iki kolona yazar. Source of truth geçici olarak eski kolon olabilir. Write failure davranışı test edilmelidir. Tek transaction içinde iki kolon güncellenebilir. Metric iki değer arasındaki farkı izleyebilir.

Historical Backfill

Eski kayıtlar batch halinde yeni kolona aktarılır. Tek büyük UPDATE kullanılmamalıdır. Checkpoint sayesinde işlem kaldığı yerden devam edebilir. Backfill production I/O'yu aşırı tüketmemelidir. Null kalan kayıtlar ayrıca kontrol edilir.

Read Path'i Yeni Kolona Taşımak

Application read önceliğini yeni kolona geçirir. Fallback kısa süre eski kolon olabilir. Mismatch metric izlenir. Canary rollout kullanılabilir. Sorun yoksa tüm trafik yeni alanı okur.

Eski Kolona Yazmayı Durdurmak

Yeni kolon source of truth olduktan sonra eski write kapatılır. Bu adım ayrı deployment olmalıdır. Eski application instance bulunmadığı doğrulanır. Audit metric eski kolon update oranını izler. Sıfır kullanım görülmeden sonraki aşamaya geçilmez.

Eski Kolonu Daha Sonra Silmek

Eski kolon hemen drop edilmemelidir. Stability window boyunca rollback için tutulabilir. Backup alınır. Dependency scan yapılır. Daha sonra contract migration ile kaldırılır.

Kolon Veri Tipi Sıfır Kesintiyle Nasıl Değiştirilir?

Büyük bir kolonun veri tipini doğrudan ALTER ile değiştirmek table rewrite ve lock yaratabilir. Daha güvenli yaklaşım hedef tipte ikinci kolon oluşturmaktır. Conversion logic application veya backfill job içinde uygulanır. Data doğrulandıktan sonra read path yeni kolona taşınır. Eski kolon contract aşamasında kaldırılır.

Yeni Tipte İkinci Kolon

Hedef veri tipine sahip yeni kolon eklenir. Existing code etkilenmez. Yeni code conversion sonucu bu alana yazabilir. Schema compatibility korunur. Storage geçici olarak artar.

Conversion Logic

Eski değer yeni tipe deterministic biçimde dönüştürülmelidir. Precision kaybı test edilmelidir. Invalid değerler ayrı raporlanmalıdır. Conversion function versionlanabilir. Business edge case'leri test edilmelidir.

Dual Write

Yeni işlemler hem eski hem yeni tipte saklanabilir. Conversion aynı request içinde yapılır. Hata durumunda transaction rollback edebilir. Mismatch metric eklenmelidir. Bu dönem geçici tutulmalıdır.

Backfill

Historical kayıtlar batch halinde dönüştürülür. Job idempotent olmalıdır. Failed row ayrı retry queue'ya alınabilir. Throughput database yüküne göre throttle edilir. Tamamlanma oranı dashboard'da görünmelidir.

Validation

Eski ve yeni değer semantic olarak karşılaştırılır. Basit string equality her zaman yeterli değildir. Aggregate ve sample validation yapılabilir. Conversion error oranı sıfır veya kabul edilen seviyede olmalıdır. Validation geçmeden read switch yapılmaz.

Read Swap

Application yeni kolon üzerinden okumaya başlar. Canary veya feature flag kullanılabilir. Eski kolon fallback olarak kısa süre tutulabilir. Latency ve error metric izlenir. Sonrasında eski read code kaldırılır.

Contract

Eski kolon dependency'leri sıfıra indiğinde drop planlanır. Backup ve restore kontrolü yapılır. Contract ayrı migration olarak çalıştırılır. Rollback artık daha zor hale gelir. Bu nedenle stability window yeterince uzun tutulmalıdır.

NOT NULL Constraint Güvenli Nasıl Eklenir?

Büyük tabloda doğrudan NOT NULL eklemek existing null kayıtlar ve validation nedeniyle risk yaratabilir. Önce nullable kolon kullanmak daha güvenlidir. Yeni code her write'ta değer üretmeye başlar. Historical null kayıtlar backfill edilir. Son doğrulama sonrasında constraint etkinleştirilir.

Nullable Kolon ile Başlamak

Kolon başlangıçta null kabul eder. Eski application böylece bozulmaz. Yeni code alanı doldurmaya başlar. Schema deployment hızlı kalır. Constraint sonraki release'e bırakılır.

Yeni Kodun Değer Yazmasını Sağlamak

Application yeni kayıtların tamamında alanı doldurur. Missing write metric izlenebilir. Eski instance'lar tamamıyla kalkana kadar dikkat gerekir. Default geçici fallback olabilir. Business value application tarafından açıkça üretilmelidir.

Historical Data'yı Backfill Etmek

Mevcut null kayıtlar batch halinde doldurulur. Job tekrar çalıştırılabilir olmalıdır. Büyük transaction'dan kaçınılır. Replica lag izlenir. İşlem sonunda null count kontrol edilir.

Null Kayıtları Kontrol Etmek

Constraint öncesi SELECT ile kalan null sayısı ölçülür. Race condition nedeniyle yeni null oluşmadığı doğrulanır. Application version kontrol edilir. Audit query birkaç kez tekrarlanabilir. Sıfır olmayan sonuçta constraint uygulanmamalıdır.

Constraint Validation

Database existing data'yı doğrular. Engine'e göre düşük lock etkili yöntem kullanılabilir. Validation load'u ölçülmelidir. Hata bulunan kayıtlar düzeltilir. Deployment ile aynı anda ağır validation çalıştırmak şart değildir.

Son Aşamada NOT NULL

Tüm verinin uyumlu olduğu kanıtlandıktan sonra NOT NULL aktif edilir. Yeni write artık database seviyesinde korunur. Application hataları erken görünür. Rollback planı yine düşünülmelidir. Constraint contract aşamasının parçası olabilir.

Foreign Key Sıfır Kesintiyle Nasıl Eklenir?

Foreign key existing data üzerinde referential integrity taraması gerektirebilir. Önce orphan kayıtlar bulunmalıdır. Constraint düşük lock etkili yöntemle eklenebilir. Validation ayrı aşamada çalıştırılabilir. Production load altında lock ve I/O etkisi ölçülmelidir.

Existing Data Integrity Kontrolü

Child kayıtların tamamının geçerli parent kaydı olup olmadığı sorgulanır. Büyük tabloda bu query optimize edilmelidir. Index gereksinimi kontrol edilir. Hatalı kayıtlar raporlanır. Constraint öncesi cleanup planı hazırlanır.

Orphan Kayıtları Bulmak

Parent karşılığı olmayan child kayıtlar orphan olarak belirlenir. Silme veya düzeltme business kararıdır. Otomatik cleanup veri kaybı yaratmamalıdır. Sonuçlar audit edilebilir olmalıdır. Cleanup tekrar çalıştırılabilir tasarlanmalıdır.

Constraint'i Ayrı Aşamada Eklemek

Foreign key application deployment'tan ayrı migration olarak uygulanabilir. Böylece lock etkisi bağımsız izlenir. Engine'in NOT VALID benzeri seçenekleri değerlendirilebilir. Yeni write korumaya alınabilir. Historical validation sonraya bırakılabilir.

Constraint Validation

Existing data foreign key kuralına göre taranır. Validation sırasında database load izlenir. Büyük tabloda uygun maintenance hızında yürütülür. Failure durumunda constraint state incelenir. Başarılı validation sonrası tam enforcement sağlanır.

Lock Etkisini Ölçmek

Foreign key ekleme belirli lock seviyeleri gerektirebilir. Staging veri hacmi production'a yakın olmalıdır. lock_timeout kullanılabilir. Query queue artışı izlenir. Risk yüksekse daha düşük trafik zamanı seçilir.

Büyük Tabloya Index Nasıl Eklenir?

Büyük tabloya index eklemek migration sırasında en sık performans sorunu yaratan işlemlerden biridir. Normal index build write trafiğini bloke edebilir veya yoğun I/O kullanabilir. Online ve concurrent yöntemler availability etkisini azaltır. Buna rağmen kaynak tüketimi ve replica lag gözlemlenmelidir. Build tamamlandıktan sonra index state ve query kullanım davranışı doğrulanmalıdır.

Normal Index Build Riski

Standart index build belirli engine'lerde güçlü lock alabilir. Büyük tablo işlemi dakikalar veya saatler sürebilir. Write request'ler bekleyebilir. Transaction queue hızla büyür. Production öncesi engine behavior doğrulanmalıdır.

Online/Concurrent Index

Online veya concurrent build normal write trafiğinin devam etmesini hedefler. İşlem genellikle daha uzun sürebilir. Ek CPU ve I/O kullanır. Failure durumunda invalid index kalabilir. Son state mutlaka kontrol edilmelidir.

Index Build Sırasında CPU ve I/O

Index oluşturma tabloyu tarar ve sort yapabilir. CPU ve disk throughput ciddi yük alır. Replica apply da etkilenebilir. Throttle veya düşük trafik zamanı kullanılabilir. SLO bozulursa işlem pause veya cancel edilmelidir.

Index Build Sonrası Validation

Index'in valid ve usable olduğu kontrol edilir. Query planner'ın index'i seçtiği EXPLAIN ile doğrulanabilir. Cardinality ve statistics güncel olmalıdır. Read latency değişimi ölçülür. Gereksiz index ise kalıcı write maliyeti yaratır.

Invalid Index Kontrolü

Concurrent build hata aldığında incomplete index metadata'sı kalabilir. Deployment aracı bunu başarı sanmamalıdır. Catalog üzerinden index state kontrol edilir. Invalid artifact gerekirse drop edilir. Retry procedure idempotent olmalıdır.

PostgreSQL'de Zero-Downtime Schema Migration

PostgreSQL schema migration planlanırken lock seviyeleri ve transaction behavior iyi anlaşılmalıdır. ACCESS EXCLUSIVE lock alan işlemler hot table üzerinde ciddi risk oluşturabilir. lock_timeout ve statement_timeout güvenlik sınırı sağlar. Concurrent index ve NOT VALID constraint yaklaşımları kesintiyi azaltabilir. Nullable column ve backfill modeli birçok breaking değişikliği aşamalı hale getirir.

PostgreSQL Lock Seviyeleri

PostgreSQL farklı DDL ve DML işlemleri için farklı lock seviyeleri kullanır. Her lock aynı blocking etkisine sahip değildir. Migration query'sinin hangi lock'u istediği bilinmelidir. Existing long transaction lock acquisition'ı geciktirebilir. Lock graph production öncesi test edilmelidir.

ACCESS EXCLUSIVE Lock

ACCESS EXCLUSIVE en güçlü table lock seviyelerinden biridir. Diğer birçok operasyonu bloke edebilir. Bazı ALTER TABLE işlemleri bunu gerektirir. Lock kısa sürecek olsa bile bekleme kuyruğu sorun yaratabilir. Hot table üzerinde kontrollü uygulanmalıdır.

lock_timeout

lock_timeout migration query'sinin lock için sınırsız beklemesini önler. Belirlenen sürede lock alınamazsa işlem hata verir. Bu davranış production trafiğini uzun süre bloke etmeyi önleyebilir. Migration tooling retry veya yeniden planlama yapabilir. Değer gerçek traffic pattern'e göre seçilmelidir.

statement_timeout

statement_timeout query'nin toplam çalışma süresini sınırlar. Beklenenden uzun migration işlemi otomatik durdurulabilir. Backfill için farklı timeout gerekebilir. Session-level ayar kullanılabilir. Timeout sonrası partial state kontrol edilmelidir.

CREATE INDEX CONCURRENTLY

CREATE INDEX CONCURRENTLY index oluştururken normal write trafiğini büyük ölçüde devam ettirmeyi hedefler. Normal build'e göre daha uzun sürebilir. Transaction içinde çalıştırma kısıtları dikkate alınmalıdır. Failure sonrası invalid index kalabilir. Deployment script final state'i doğrulamalıdır.

REINDEX CONCURRENTLY

REINDEX CONCURRENTLY mevcut index'i daha düşük blocking etkisiyle yeniden oluşturmayı amaçlar. Bloat veya index bakımında yararlı olabilir. Ek disk alanı gerekebilir. Production load izlenmelidir. Sürüm desteği ve davranışı kullanılan PostgreSQL ortamında doğrulanmalıdır.

NOT VALID Constraint

Foreign key veya check constraint mevcut tüm data hemen taranmadan eklenebilir. Yeni write için kural uygulanabilir. Historical validation ayrı aşamaya bırakılır. Bu yöntem deployment süresini kısaltır. Sonrasında VALIDATE CONSTRAINT unutulmamalıdır.

VALIDATE CONSTRAINT

Existing data constraint kuralına göre doğrulanır. Bu işlem ayrı maintenance adımı olarak çalıştırılabilir. Lock etkisi doğrudan add constraint işleminden farklı olabilir. Production I/O yine izlenmelidir. Başarılı validation sonrası constraint tam güvence sağlar.

Nullable Column + Backfill

Yeni kolon önce nullable eklenir. Application yeni değer yazmaya başlar. Historical kayıtlar küçük batch'lerle doldurulur. Null count sıfıra indikten sonra constraint eklenir. Bu model büyük table rewrite riskini azaltır.

PostgreSQL Online Migration Araçları

PostgreSQL ekosisteminde online schema değişikliklerini kolaylaştıran farklı araç ve yaklaşımlar bulunur. pg_repack belirli tablo ve index bakım işlemlerinde, pgroll ve Reshape benzeri yaklaşımlar compatibility odaklı schema değişikliklerinde kullanılabilir. Native PostgreSQL teknikleri birçok durumda ek araç olmadan yeterlidir. Araç seçimi table size, lock riski ve operasyon ekibi deneyimine göre yapılmalıdır. Her araç production'a alınmadan önce staging üzerinde failure ve rollback testine tabi tutulmalıdır.

pg_repack

pg_repack table veya index bloat azaltma gibi operasyonlarda düşük blocking yaklaşım sunabilir. Ek disk alanı gerektirir. Trigger veya metadata davranışı incelenmelidir. Büyük table üzerinde I/O etkisi vardır. Production kullanımından önce mevcut sürüm uyumluluğu kontrol edilmelidir.

pgroll

pgroll schema değişikliklerini backward-compatible rollout yaklaşımıyla ele almayı hedefleyen araçlardan biridir. Eski ve yeni application version'larının birlikte çalışması düşünülür. Migration otomasyonu manual hata riskini azaltabilir. Her schema işlemi eşit derecede güvenli değildir. Tool behavior gerçek application pattern'iyle test edilmelidir.

Reshape

Reshape benzeri araçlar PostgreSQL schema dönüşümünü online yürütmeyi hedefler. Shadow yapı ve change synchronization yaklaşımı kullanılabilir. Büyük table migration'ında yardımcı olabilir. Tool'un desteklediği DDL kapsamı incelenmelidir. Recovery ve rollback prosedürü ayrıca test edilmelidir.

Native PostgreSQL Teknikleri

Concurrent index, logical replication ve staged constraint validation birçok migration'ı ek araç olmadan çözebilir. Native özellikler operasyon yüzeyini azaltır. Ancak otomasyon yine gerekir. Version-specific behavior production sürümünde doğrulanmalıdır. Her native özellik zero downtime garantisi vermez.

Hangi Durumda Hangi Araç?

Basit index ve constraint değişikliklerinde native PostgreSQL genellikle yeterlidir. Table rewrite riski yüksek değişikliklerde online tooling değerlendirilebilir. Bloat problemi pg_repack gibi farklı bir araç sınıfına girer. Cross-database migration CDC gerektirir. Seçim feature listesi yerine gerçek failure ve rollback ihtiyacına göre yapılmalıdır.

MySQL'de Zero-Downtime Schema Migration

MySQL online DDL yetenekleri schema migration sırasında lock etkisini önemli ölçüde azaltabilir. ALGORITHM seçimi işlemin metadata seviyesinde mi, inplace mi yoksa copy ile mi yapılacağını etkiler. LOCK=NONE hedeflense de her ALTER işlemi aynı davranışı desteklemez. EXPLAIN ALTER TABLE benzeri yeteneklerle plan önceden incelenebilir. Büyük production table üzerinde ALTER davranışı kullanılan sürümde mutlaka doğrulanmalıdır.

Online DDL

Online DDL table değişikliği sırasında read ve write trafiğinin devam etmesini hedefler. Destek kapsamı ALTER türüne göre değişir. Bazı işlemler yine rebuild gerektirebilir. Temporary disk kullanımı artabilir. Production workload ile benchmark yapılmalıdır.

ALGORITHM=INSTANT

INSTANT belirli schema değişikliklerini veri satırlarını yeniden yazmadan metadata seviyesinde tamamlayabilir. Bu nedenle çok hızlı olabilir. Her ALTER türü tarafından desteklenmez. Version farkları önemlidir. Unsupported işlemde beklenmeyen fallback engellenmelidir.

ALGORITHM=INPLACE

INPLACE bazı değişiklikleri full table copy olmadan uygular. Yine de internal rebuild veya resource kullanımı olabilir. Lock behavior işlem türüne göre değişir. I/O etkisi ölçülmelidir. Büyük table üzerinde süresi önceden bilinmelidir.

ALGORITHM=COPY

COPY yeni table oluşturarak veriyi yeniden taşır. Büyük dataset'te uzun ve pahalı olabilir. Disk alanı gerektirir. Write blocking riski yüksektir. Hot production table için alternatif online yöntem aranmalıdır.

LOCK=NONE

LOCK=NONE normal DML trafiğinin devam etmesini hedefler. Her DDL bunu desteklemez. Engine gerekli görürse farklı lock behavior oluşabilir. Explicit algorithm ve lock seçenekleri güvenli beklenti sağlar. Failure behavior staging'de test edilmelidir.

EXPLAIN ALTER TABLE

ALTER işleminin nasıl uygulanacağını önceden görmek risk analizine yardım eder. Table rebuild ihtiyacı anlaşılabilir. Algorithm ve lock behavior doğrulanabilir. Production DDL öncesi plan kontrolü yapılmalıdır. CI pipeline destructive veya pahalı planları engelleyebilir.

Hangi ALTER İşlemleri Table Rebuild Gerektirir?

Bu cevap MySQL sürümü ve ALTER türüne göre değişir. Data type değişimi veya bazı index operasyonları rebuild gerektirebilir. Varsayım yerine gerçek sürüm üzerinde EXPLAIN ve test kullanılmalıdır. Table size migration süresini doğrudan etkiler. CI kuralı pahalı ALTER'ları manuel onaya yönlendirebilir.

gh-ost ile MySQL Online Schema Migration

gh-ost büyük MySQL tablolarında online schema değişikliği için ghost table yaklaşımı kullanır. Source değişikliklerini binlog üzerinden izler. Data yeni table'a incremental olarak kopyalanır. Throttling ve pause özellikleri production load'a uyum sağlamaya yardımcı olur. Final cutover kontrollü biçimde gerçekleştirilir.

Ghost Table Mantığı

Yeni schema ile ayrı ghost table oluşturulur. Mevcut table anında ALTER edilmez. Historical data ghost table'a kopyalanır. Source değişiklikleri ayrıca takip edilir. Cutover sonunda table isimleri kontrollü değiştirilebilir.

Binlog ile Değişiklik Takibi

gh-ost source table değişikliklerini MySQL binlog üzerinden okuyabilir. Trigger ekleme ihtiyacını azaltır. Write trafiği ghost table'a uygulanır. Binlog retention yeterli olmalıdır. Lag veya disconnect durumu izlenmelidir.

Incremental Copy

Data küçük chunk'lar halinde taşınır. Büyük tek transaction oluşmaz. Production yüküne göre hız ayarlanabilir. Checkpoint mantığı recovery'yi kolaylaştırır. Copy progress görünür olmalıdır.

Throttling

Database load belirli eşiği aşarsa migration yavaşlatılabilir. Replica lag veya CPU sinyali kullanılabilir. Kullanıcı trafiği migration hızından önceliklidir. Throttle policy otomatik olmalıdır. Normal load geri geldiğinde migration devam eder.

Pause

Migration gerektiğinde geçici olarak durdurulabilir. Source write trafiği devam eder. Tool change stream'i güvenli biçimde yönetmelidir. Pause incident sırasında useful safety control sağlar. Resume behavior önceden test edilmelidir.

Test on Replica

Gerçek source table üzerinde çalışmadan önce replica üzerinde behavior test edilebilir. Süre ve load tahmini yapılır. Schema sonucu doğrulanır. Failure case gözlemlenir. Production cutover için risk azalır.

Controlled Cutover

Final swap kısa ama kritik adımdır. Lock acquisition ve application behavior izlenir. Cutover şartları önceden belirlenir. Gerekirse süreç bekletilebilir. Swap sonrası query ve error metric hemen kontrol edilmelidir.

pt-online-schema-change Nasıl Çalışır?

pt-online-schema-change mevcut tabloyu doğrudan değiştirmek yerine yeni bir shadow table oluşturur. Existing data chunk'lar halinde yeni table'a taşınır. Source değişiklikleri trigger tabanlı olarak target'a yansıtılır. Tamamlandığında atomic swap ile yeni table devreye alınır. Trigger yaklaşımı nedeniyle gh-ost ile operasyon modeli farklıdır.

Shadow Table

Hedef schema ile yeni table oluşturulur. Existing production table write almaya devam eder. Data shadow table'a taşınır. Index ve constraint hedef yapı üzerinde hazırlanır. Cutover öncesi iki taraf senkron tutulur.

Trigger Tabanlı Change Capture

Source insert, update ve delete işlemleri trigger ile shadow table'a aktarılır. Bu yaklaşım application değişikliği gerektirmez. Trigger write path'e ek maliyet getirir. Existing trigger'larla uyumluluk incelenmelidir. High write workload altında benchmark yapılmalıdır.

Chunked Copy

Historical data küçük chunk'lar halinde taşınır. Transaction süresi sınırlı kalır. Chunk size database load'a göre ayarlanabilir. Replica lag sinyali kullanılabilir. Migration production trafiğini bozmamalıdır.

Atomic Swap

Copy tamamlandıktan sonra table isimleri kontrollü şekilde değiştirilir. Bu final cutover kısa lock gerektirebilir. Connection ve metadata behavior test edilmelidir. Eski table kısa süre rollback için saklanabilir. Swap sonrası validation yapılmalıdır.

gh-ost ile Farkları

En temel fark change capture yöntemidir. pt-online-schema-change trigger kullanırken gh-ost binlog tabanlı yaklaşım sunar. Trigger write overhead oluşturabilir. gh-ost operasyon kontrolünü farklı biçimde sağlar. Seçim topology ve ekip deneyimine göre yapılmalıdır.

Change Data Capture (CDC) Nedir?

Change Data Capture source database üzerinde oluşan insert, update ve delete değişikliklerini sürekli yakalayıp hedefe aktarma yöntemidir. Transaction log tabanlı CDC production write yoluna doğrudan application değişikliği eklemeden çalışabilir. Genellikle önce initial full load yapılır. Ardından full load sırasında oluşan yeni değişiklikler CDC ile uygulanır. Target source'a yetiştiğinde cutover gerçekleştirilebilir.

Transaction Log Tabanlı Replication

CDC database transaction log'unu değişiklik kaynağı olarak kullanabilir. PostgreSQL WAL veya MySQL binlog örnek verilebilir. Query polling ihtiyacı azalır. Ordering ve transaction metadata korunabilir. Log retention migration süresince yeterli olmalıdır.

Initial Full Load

Existing dataset target database'e toplu olarak taşınır. Büyük dataset için parallel load kullanılabilir. Snapshot tutarlılığı önemlidir. Full load source production trafiğini bozmamalıdır. Copy başlangıç position'ı CDC ile ilişkilendirilmelidir.

Ongoing Replication

Full load devam ederken yeni source değişiklikleri yakalanır. Bu event'ler target'a uygulanır. Migration saatler sürse bile target güncel kalabilir. Apply rate write rate'in üzerinde olmalıdır. Lag kapanmadan final cutover yapılmaz.

CDC Lag

CDC lag source değişikliği ile target apply arasındaki gecikmedir. Network veya target write saturation lag'i büyütebilir. Büyük transaction tek seferde ciddi backlog oluşturabilir. Dashboard lag trendini göstermelidir. Quality gate cutover öncesi maksimum lag belirlemelidir.

Final Cutover

Target source'a yeterince yaklaştığında write routing değiştirilebilir. Son transaction position doğrulanır. Single writer prensibi korunur. Application target'a geçtikten sonra source read-only olabilir. Reverse sync rollback için kısa süre tutulabilir.

PostgreSQL CDC Nasıl Çalışır?

PostgreSQL CDC genellikle WAL ve logical decoding mekanizmalarından yararlanır. Replication slot consumer'ın ihtiyaç duyduğu WAL segmentlerinin korunmasına yardımcı olur. LSN source ve target ilerlemesini karşılaştırmak için kullanılabilir. Consumer geride kalırsa slot lag büyür ve disk tüketimi artar. Bu nedenle CDC pipeline sağlık metriği migration dashboard'unun merkezinde olmalıdır.

WAL

Write-Ahead Log transaction değişikliklerini kalıcı sırayla kaydeder. PostgreSQL recovery ve replication süreçlerinin temelidir. CDC WAL içindeki değişiklikleri logical event'e dönüştürebilir. Yüksek write throughput büyük WAL hacmi üretir. Disk kapasitesi sürekli izlenmelidir.

Logical Replication

Logical replication table-level değişiklikleri logical formatta aktarabilir. Source ve target major version farklılıklarında useful olabilir. Schema uyumu ayrıca yönetilmelidir. Publication ve subscription modeli kullanılabilir. Sequence davranışı ayrıca doğrulanmalıdır.

Replication Slot

Replication slot consumer'ın okumadığı WAL'ın erken silinmesini önleyebilir. Consumer uzun süre durursa retained WAL büyür. Disk dolması production incident yaratabilir. Slot lag alarmı zorunludur. Kullanılmayan slot'lar kaldırılmalıdır.

LSN

Log Sequence Number WAL içindeki ilerleme pozisyonunu temsil eder. Source commit ile consumer apply arasındaki fark ölçülebilir. Cutover point LSN üzerinden takip edilebilir. Transaction boundary önemlidir. Migration logları position bilgisini saklamalıdır.

Slot Lag

Slot lag consumer'ın source WAL ilerlemesinden ne kadar geride olduğunu gösterir. Byte farkı ve zaman farkı ayrı anlam taşır. Büyüyen lag target apply sorunu gösterebilir. Migration throttle buna göre ayarlanabilir. Disk retention threshold önceden belirlenmelidir.

WAL Retention

Migration uzun sürerse gerekli WAL segmentlerinin korunması gerekir. Retention yetersizse CDC yeniden initial load gerektirebilir. Aşırı retention source diskini doldurabilir. Capacity forecast yapılmalıdır. Alarm hem süre hem byte üzerinden kurulmalıdır.

MySQL CDC Nasıl Çalışır?

MySQL CDC çoğunlukla binary log üzerinden source değişikliklerini takip eder. Row-based binlog veri değişikliklerini satır seviyesinde temsil eder. Binlog position veya GTID progress takibinde kullanılabilir. Log retention migration süresi boyunca yeterli olmalıdır. Target'ın apply kapasitesi source write throughput'unu karşılamalıdır.

Binary Log

Binlog MySQL write değişikliklerini replication amacıyla kaydeder. CDC consumer bu akışı okuyabilir. Binlog configuration migration öncesi doğrulanmalıdır. Retention kısa ise consumer gap yaşayabilir. Storage maliyeti kapasite planına dahil edilmelidir.

Row-Based Binlog

Row-based format değişen satır değerlerini loglar. CDC için deterministic değişiklik kaynağı sağlar. Event hacmi yoğun write workload'da büyüyebilir. Large blob alanları network kullanımını artırır. Consumer throughput buna göre boyutlandırılmalıdır.

Binlog Position

File ve offset benzeri position source ilerlemesini gösterir. Migration initial snapshot bu position ile bağlanabilir. Consumer restart sonrası buradan devam eder. Position metadata durable saklanmalıdır. Failover sonrası behavior ayrıca düşünülmelidir.

GTID

GTID transaction'lara global identifier sağlar. Replication topology değişikliklerinde tracking kolaylaşabilir. Cutover ve failover süreçleri daha yönetilebilir olur. GTID configuration migration öncesi doğrulanmalıdır. Target support ve consistency kontrol edilmelidir.

Log Retention

Binlog consumer tamamlamadan silinmemelidir. Migration günler sürüyorsa retention artırılabilir. Disk kapasitesi izlenmelidir. Consumer lag threshold alarm üretmelidir. Migration bittikten sonra geçici retention ayarı normale alınabilir.

CDC Kullanırken Hangi Riskler İzlenmelidir?

CDC güçlü bir migration tekniğidir ancak kendi failure mode'larına sahiptir. Replication lag ve transaction log retention en kritik iki konudur. Consumer durursa source disk dolabilir. Unsupported DDL veya büyük transaction target apply sürecini bozabilir. Ordering ve target write kapasitesi sürekli gözlemlenmelidir.

Replication Lag

CDC target source'dan geride kalabilir. Lag yükselirken cutover yapılmamalıdır. Apply rate ve source write rate karşılaştırılır. Root cause network veya target database olabilir. Alarm yalnızca mutlak süre değil trend de izlemelidir.

Transaction Log Retention

Consumer gerekli log'a erişemiyorsa migration zinciri kırılabilir. Retention migration duration ve failure recovery süresini kapsamalıdır. Source disk kapasitesi yeterli olmalıdır. Slot veya binlog cleanup kontrollü yapılmalıdır. Runbook log kaybı senaryosunu içermelidir.

Disk Dolması

CDC consumer durduğunda retained WAL veya binlog büyüyebilir. Source database disk dolarsa production write etkilenir. Disk alarmı yüksek öncelikli olmalıdır. Emergency slot cleanup ciddi data sync kaybı yaratabilir. Capacity buffer migration başlamadan ayrılmalıdır.

Unsupported DDL

CDC tool bazı schema değişikliklerini otomatik replike etmeyebilir. Source ve target schema drift oluşabilir. Migration sırasında DDL freeze uygulanabilir. Desteklenen değişiklikler runbook'a yazılmalıdır. Unexpected DDL CI/CD seviyesinde engellenebilir.

Large Transactions

Çok büyük transaction CDC pipeline'da uzun süre tek event grubu olarak kalabilir. Memory ve apply latency artabilir. Target commit süresi uzar. Lag bir anda sıçrayabilir. Büyük batch workload migration öncesi küçültülebilir.

Target Write Capacity

Target full load ve CDC'yi aynı anda taşıyabilmelidir. Index'ler write amplification oluşturabilir. Parallel load fazla agresif olursa CDC geride kalır. Resource priority CDC lehine ayarlanabilir. Cutover için target steady-state write kapasitesi ayrıca test edilmelidir.

Ordering

Aynı entity üzerindeki değişikliklerin doğru sırada uygulanması gerekir. Parallel consumer ordering'i bozabilir. Transaction boundary korunmalıdır. Idempotency duplicate delivery riskini azaltır. Business invariant ordering modeline bağlıysa ayrıca test edilmelidir.

Full Load + CDC Modeli

Full Load + CDC modeli büyük migration'larda en pratik yaklaşımlardan biridir. Önce tutarlı snapshot noktası belirlenir. Historical data target'a aktarılırken source üzerinde oluşan yeni değişiklikler CDC tarafından kaydedilir. Full load tamamlandığında backlog uygulanır. Lag kabul edilebilir seviyeye indiğinde cutover yapılır.

Snapshot Başlatmak

Migration belirli tutarlı source state'inden başlamalıdır. Snapshot transaction boundary ile ilişkilendirilir. Uzun snapshot source kaynaklarını etkileyebilir. Engine behavior test edilmelidir. Başlangıç zamanı audit log'a yazılır.

CDC Position Kaydetmek

Snapshot ile aynı anda WAL LSN veya binlog position kaydedilir. Böylece full load sonrası hangi değişikliklerin uygulanacağı bilinir. Position kaybolmamalıdır. Migration metadata store içinde tutulur. Restart sonrası aynı noktadan devam edilir.

Historical Data'yı Taşımak

Mevcut tablolar batch veya parallel worker ile target'a kopyalanır. Büyük tablolar chunk'lara bölünür. Network ve target I/O izlenir. Retry duplicate veri üretmemelidir. Progress table bazında ölçülür.

Bu Sırada Yeni Değişiklikleri Yakalamak

Source production write almaya devam eder. CDC bu değişiklikleri transaction log'dan okur. Event'ler buffer veya target apply kuyruğunda tutulur. Retention yeterli olmalıdır. Source write path application açısından değişmez.

Full Load Sonrası Değişiklikleri Uygulamak

Historical copy tamamlanınca CDC backlog target'a uygulanır. Apply throughput source write hızından yüksek tutulmalıdır. Lag zamanla küçülür. Duplicate event idempotent işlenir. Error queue temizlenmeden cutover yapılmaz.

Lag'i Sıfıra Yaklaştırmak

Final cutover öncesi target source'a mümkün olduğunca yaklaşmalıdır. Gerekirse full load worker'ları durdurulup CDC'ye kaynak ayrılır. Çok kısa writer pause bazı sistemlerde son farkı kapatabilir. Zero planned downtime hedefinde bu pause kullanıcıya yansıtılmayabilir. Son position doğrulanmalıdır.

Dual Write Pattern Nedir?

Dual write application'ın aynı business değişikliğini source ve target database'e yazmasıdır. Migration sırasında iki sistemi güncel tutmak için kullanılabilir. Ancak iki bağımsız write tek atomic transaction içinde değilse partial failure riski oluşur. Bu nedenle source of truth açıkça belirlenmelidir. İdempotency, retry ve reconciliation dual write tasarımının temel parçalarıdır.

Kaynak ve Hedefe Aynı Anda Yazmak

Application write request'inde iki database çağrısı yapar. Source başarılı target başarısız olabilir. Ters durum da mümkündür. Response semantics önceden belirlenmelidir. Her write unique idempotency key taşımalıdır.

Source of Truth Belirlemek

Migration boyunca hangi database'in canonical state olduğu net olmalıdır. Genellikle cutover öncesi source bu rolü taşır. Target mismatch olduğunda source referans alınır. Writer switch sonrası rol değişir. Belirsiz ownership split-brain riski yaratır.

Partial Write Failure

İki write'tan yalnızca biri başarılı olabilir. Network timeout gerçek sonucu belirsiz bırakabilir. Retry duplicate veya farklı state üretebilir. Durable reconciliation queue gerekir. Kullanıcı cevabı source of truth sonucuna göre verilebilir.

Retry

Başarısız target write yeniden denenebilir. Retry exponential backoff ve jitter kullanmalıdır. Sonsuz retry production kaynaklarını tüketmemelidir. Dead letter queue son çare olarak kullanılabilir. Retry işlemi idempotent olmalıdır.

Idempotency

Aynı write tekrar gönderildiğinde sonuç değişmemelidir. Request veya event unique key taşıyabilir. Target duplicate operation'ı tanıyabilir. Upsert veya version check kullanılabilir. Migration recovery için bu özellik çok değerlidir.

Duplicate Write

Timeout sonrası aynı event iki kez uygulanabilir. Counter veya payment gibi işlemlerde duplicate ciddi risk taşır. Event ID ile deduplication gerekir. Database unique constraint yardımcı olabilir. Consumer at-least-once semantiğine dayanıklı olmalıdır.

Dual Write'ın Riskleri

Dual write application code'u migration logic ile yükler. İki database latency'si request süresini artırabilir. Partial failure state divergence yaratır. Rollback writer değiştikten sonra daha zor hale gelir. CDC mümkünse daha düşük application coupling sağlayabilir.

Dual Write Nasıl Daha Güvenilir Hale Getirilir?

Dual write'ın en büyük problemi iki ayrı sisteme yapılan write'ın atomik olmamasıdır. Transactional outbox bu problemi source database transaction'ı içinde publish niyetini kaydederek azaltabilir. Event queue target write'ı asynchronous hale getirir. Idempotency key duplicate event'i güvenli kılar. Reconciliation job iki taraf arasındaki farkı düzenli olarak kontrol eder.

Transactional Outbox

Business write ile outbox event aynı local transaction içinde commit edilir. Broker geçici kapalı olsa bile event kaybolmaz. Publisher daha sonra event'i gönderir. Duplicate publish mümkündür. Consumer idempotent olmalıdır.

Event Queue

Target update request path'ten ayrılabilir. Queue temporary target failure'ı absorbe eder. Backpressure doğal olarak görünür hale gelir. Queue depth migration health metriği olabilir. Ordering gereksinimi partition key ile yönetilir.

Idempotency Key

Her migration event unique identifier taşır. Target daha önce işlendiğini kontrol eder. Duplicate retry aynı state'i yeniden üretmez. Key retention süresi migration penceresini kapsamalıdır. Business operation ID iyi aday olabilir.

Retry Queue

Geçici hatalar ayrı retry queue'ya alınabilir. Backoff target'ı aşırı yükten korur. Retry count metric olarak izlenir. Permanent error ayrıştırılmalıdır. Queue sonsuz büyümemelidir.

Dead Letter Queue

Belirli sayıda retry sonrası başarısız event DLQ'ya gönderilir. Operator veya repair job bu kayıtları inceler. Payload ve hata nedeni saklanmalıdır. Hassas veri korunmalıdır. DLQ sıfır olmadan final migration tamamlanmamalıdır.

Reconciliation Job

Source ve target periyodik olarak karşılaştırılır. Missing veya mismatched kayıtlar bulunur. Repair operation idempotent olmalıdır. Business aggregate kontrolü yapılabilir. Cutover öncesi mismatch trendi sıfıra yaklaşmalıdır.

CDC mi Dual Write mı?

CDC ve dual write aynı hedefe farklı katmanlardan yaklaşır. CDC database log üzerinden değişiklik yakalar ve application code'u daha az etkiler. Dual write application'a daha fazla kontrol verir ancak consistency riski yüksektir. Rollback ve latency ihtiyaçları seçimde önemlidir. Bazı migration'larda iki yöntem kısa süre birlikte de kullanılabilir.

Application Değişikliği

CDC çoğu durumda application write path'ini değiştirmez. Dual write yeni connection ve retry logic gerektirir. Application deployment riskini artırabilir. Buna karşılık domain transformation doğrudan code içinde yapılabilir. Mevcut architecture seçimi etkiler.

Data Consistency

CDC source transaction log'u canonical değişiklik akışı olarak kullanır. Ordering ve transaction boundary daha doğal korunabilir. Dual write partial failure riski taşır. Reconciliation iki modelde de faydalıdır. Strong consistency gereksinimi ayrıca değerlendirilmelidir.

Operational Complexity

CDC connector, slot ve log retention yönetimi gerektirir. Dual write application, queue ve retry sistemi gerektirir. Hangi ekibin hangi sistemi daha iyi işlettiği önemlidir. Basit görünüm yanıltıcı olabilir. Failure mode sayısı karşılaştırılmalıdır.

Latency

CDC asynchronous olduğunda kullanıcı write latency'sini doğrudan artırmaz. Dual write synchronous yapılırsa iki database response'u beklenebilir. Async dual write queue ile ayrılabilir. Target freshness ihtiyacı latency modelini belirler. Cutover öncesi lag her durumda ölçülmelidir.

Rollback

CDC yönü source'tan target'a ise cutover sonrası reverse path gerekebilir. Dual write iki tarafı güncel tuttuğu için kısa süre rollback kolay görünebilir. Ancak divergence varsa risk büyür. Single writer ownership korunmalıdır. Rollback procedure gerçek testten geçmelidir.

Hangi Senaryoda Hangisi?

Engine log erişimi güçlü ve application değişikliği istenmiyorsa CDC iyi adaydır. Domain-level transformation gerekiyorsa dual write düşünülebilir. Very low latency target sync için application event modeli yararlı olabilir. Heterogeneous migration dönüşüm ihtiyacı artırır. Karar failure ve recovery gereksinimine göre verilmelidir.

Historical Backfill Nasıl Yapılır?

Historical backfill geçmiş kayıtların yeni schema veya target database'e kontrollü biçimde aktarılmasıdır. Backfill doğrudan schema migration transaction'ı içinde yapılmamalıdır. Batch ve primary-key range kullanmak işlemi kontrol edilebilir hale getirir. Checkpoint sayesinde job restart sonrası devam edebilir. Throttling production trafiğini migration hızından daha öncelikli tutar.

Backfill'i Migration Dosyasından Ayırmak

Schema migration hızlı ve predictable kalmalıdır. Milyonlarca row update migration dosyasını saatlerce açık tutabilir. Application deployment bloke olur. Backfill ayrı worker veya job olarak çalıştırılmalıdır. Progress ve retry bağımsız yönetilir.

Batch Processing

Data küçük gruplar halinde işlenir. Her batch ayrı transaction olabilir. Lock süresi kısa kalır. Failure yalnızca küçük bölümü etkiler. Batch size load metric'e göre ayarlanabilir.

Primary-Key Range

Sequential veya ordered primary key chunking için kullanılabilir. Last processed ID checkpoint olarak tutulur. OFFSET kullanımından daha predictable olabilir. Deleted ID gap sorun oluşturmaz. Range boyutu dynamic ayarlanabilir.

Checkpoint

Job hangi noktaya kadar tamamlandığını durable biçimde kaydeder. Restart sonrası baştan başlamaz. Checkpoint transaction ile birlikte güncellenebilir. Çok seyrek checkpoint tekrar iş miktarını artırır. Çok sık checkpoint ek write overhead yaratabilir.

Resume

Job deployment veya failure sonrası devam edebilmelidir. Aynı batch yeniden çalışsa bile sonuç güvenli olmalıdır. Lock ve connection state yeniden oluşturulur. Resume operation manual müdahale gerektirmemelidir. Progress doğru yerden devam etmelidir.

Throttling

Backfill CPU veya replica lag yükseldiğinde yavaşlatılabilir. Sleep veya token rate kullanılabilir. Migration tamamlanma süresi uzasa bile production SLO korunur. Peak saatlerde daha düşük hız seçilebilir. Throttle metric-driven olmalıdır.

Retry

Transient database hataları belirli policy ile yeniden denenir. Retry tüm batch'i veya tek kaydı kapsayabilir. Permanent data error ayrı loglanır. Exponential backoff kullanılabilir. Retry count dashboard'da görünmelidir.

Backfill Neden Idempotent Olmalıdır?

Uzun süren backfill işlemleri network, deployment veya database failure nedeniyle mutlaka yeniden başlayabilir. Aynı batch tekrar işlendiğinde data bozulmamalıdır. Upsert veya koşullu update bunu kolaylaştırabilir. Checkpoint crash recovery süresini azaltır. At-least-once processing varsayımı daha dayanıklı migration tasarımı oluşturur.

Aynı Batch'in Tekrar Çalışması

Job commit sonrası checkpoint yazmadan çökerse aynı batch yeniden çalışabilir. Operation duplicate effect üretmemelidir. Deterministic conversion bunu kolaylaştırır. Counter increment gibi işlemler dikkat ister. Test suite duplicate execution senaryosu içermelidir.

Upsert

Target kaydı varsa update, yoksa insert yapılabilir. Unique key doğru seçilmelidir. Upsert duplicate row riskini azaltır. Existing newer data'nın üzerine yazılmamalıdır. Version veya timestamp condition kullanılabilir.

Checkpoint

Checkpoint ilerlemeyi durable olarak kaydeder. Data commit ile checkpoint consistency düşünülmelidir. Ayrı transaction küçük duplicate işlem riski yaratabilir. Idempotency bu riski tolere eder. Progress metric buradan üretilebilir.

Crash Recovery

Worker beklenmeyen şekilde durabilir. Restart sonrası son güvenli checkpoint'ten devam eder. Manual data temizliği gerekmemelidir. Partial batch state güvenli şekilde tekrar işlenir. Recovery süresi operasyon hedefidir.

At-Least-Once Processing

Her kaydın en az bir kez işleneceği varsayımı duplicate olasılığını kabul eder. Exactly-once beklentisi çoğu distributed pipeline'da pahalıdır. Idempotent target operation daha pratiktir. Duplicate metric yine izlenebilir. Business side effect dikkatle tasarlanmalıdır.

Backfill Production Trafiğini Nasıl Etkilememeli?

Backfill'in amacı migration'ı hızla bitirmek değil, production'u bozmadan tamamlamaktır. Batch size ve sleep süresi database yüküne göre ayarlanmalıdır. CPU, disk I/O ve transaction log üretimi izlenmelidir. Replica lag yükseliyorsa backfill hızı düşürülmelidir. PostgreSQL ortamında autovacuum etkisi gibi database-specific maintenance davranışları da hesaba katılmalıdır.

Batch Size

Büyük batch throughput'u artırabilir ancak lock ve transaction süresini uzatır. Küçük batch daha kontrollüdür. Optimal değer gerçek workload ile bulunur. Dynamic batch sizing kullanılabilir. p99 latency yükselirse batch küçültülmelidir.

Sleep/Throttle

Batch'ler arasına kısa bekleme konulabilir. Database normale döner. Peak saatlerde throttle artırılabilir. Metric-based controller daha verimli olur. Migration bitiş süresi secondary hedeftir.

CPU

Backfill conversion ve update işlemleri CPU tüketir. Source ve target ayrı izlenmelidir. CPU saturation query latency'yi yükseltebilir. Headroom korunmalıdır. Threshold üzerinde worker concurrency azaltılabilir.

Disk I/O

Bulk update büyük write I/O üretir. Index güncellemeleri ek maliyet getirir. Disk latency yükselirse kullanıcı query'leri etkilenir. Backfill hız sınırı uygulanmalıdır. Storage throughput migration öncesi ölçülmelidir.

WAL/Binlog Üretimi

Her update transaction log üretir. Büyük backfill log hacmini ciddi artırabilir. Replica ve CDC consumer bu yükü işlemelidir. Retention storage büyür. Log rate dashboard'da görünmelidir.

Replica Lag

Backfill primary üzerinde hızlı çalışırken replica apply geride kalabilir. Read replica stale hale gelir. Failover kalitesi düşer. Lag threshold backfill throttle'a bağlanabilir. Replica toparlanmadan hız artırılmamalıdır.

Autovacuum

PostgreSQL update işlemleri dead tuple üretir. Büyük backfill autovacuum ihtiyacını artırabilir. Vacuum aynı anda I/O tüketebilir. Table bloat izlenmelidir. Migration sonrası maintenance planı yapılmalıdır.

Migration Veri Doğrulaması Nasıl Yapılır?

Migration validation source ve target'ın aynı business state'i taşıdığını kanıtlamayı amaçlar. Row count hızlı başlangıçtır ancak tek başına yeterli değildir. Checksums, primary-key comparison ve column-level comparison daha güçlü kontrol sağlar. Referential integrity ve business totals ayrıca ölçülmelidir. Cutover yalnızca validation sonucu kabul edilen eşik içindeyse yapılmalıdır.

Row Count

Source ve target table row count karşılaştırılır. Büyük tabloda exact count pahalı olabilir. Approximate metadata yalnızca ön kontrol olarak kullanılabilir. Count eşitliği içerik eşitliğini garanti etmez. Diğer validation yöntemleriyle tamamlanmalıdır.

Checksums

Data chunk'ları deterministic checksum ile karşılaştırılabilir. Sort order ve serialization aynı olmalıdır. Büyük dataset parallel validate edilebilir. Mismatch chunk daha ayrıntılı incelenir. Hash seçimi collision riskine göre yapılmalıdır.

Primary-Key Comparison

Source ve target ID setleri karşılaştırılır. Missing ve extra kayıtlar bulunur. Büyük dataset range veya streaming yöntemle işlenir. Global sort memory'ye alınmamalıdır. Difference count migration metriği olarak izlenir.

Column-Level Comparison

Aynı primary key için kritik kolonlar karşılaştırılır. Timestamp precision veya normalization farklılıkları dikkate alınmalıdır. Tüm kolonları karşılaştırmak pahalı olabilir. Riskli alanlar önceliklendirilebilir. Mismatch örnekleri ayrı loglanır.

Aggregate Comparison

SUM, COUNT ve GROUP BY gibi aggregate sonuçlar iki tarafta karşılaştırılır. Business total farkı hızlı signal verir. Aggregate eşitliği row-level eşitliği garanti etmez. Yine de büyük dataset'te faydalıdır. Tenant bazlı aggregate skew'u gösterebilir.

Referential Integrity

Foreign key ilişkileri target üzerinde kontrol edilir. Orphan kayıtlar aranır. Heterogeneous migration constraint conversion hatası gösterebilir. Integrity check incremental yapılabilir. Critical relation sıfır hata hedeflemelidir.

Business Rule Validation

Database equality her zaman business correctness anlamına gelmez. Toplam aktif kullanıcı veya tamamlanmış sipariş sayısı gibi domain metric'ler karşılaştırılmalıdır. Application logic ile doğrulama yapılabilir. Financial total gibi kritik metrikler ayrı kontrol edilir. Business owner sonuçları görmelidir.

Shadow Read Nedir?

Shadow read production read request'ini target database üzerinde kullanıcı sonucunu değiştirmeden tekrar çalıştırma yöntemidir. Kullanıcı hâlâ source cevabını alır. Target sonucu source ile karşılaştırılır. Mismatch rate ve latency böylece gerçek trafik üzerinde ölçülebilir. Target load kapasitesi shadow trafiğini kaldıracak şekilde planlanmalıdır.

Kullanıcı Cevabını Eski DB'den Vermek

Source migration sırasında canonical read path olmaya devam eder. Kullanıcı target hatasından etkilenmez. Existing cache ve latency davranışı korunur. Response normal biçimde döner. Target call asynchronous yapılabilir.

Aynı Read'i Yeni DB'ye Göndermek

Request'in aynısı target üzerinde çalıştırılır. Sensitive side effect oluşturan query kullanılmamalıdır. Read-only connection tercih edilir. Sampling tüm trafiğin kopyalanmasını önleyebilir. Query parameter'ları güvenli şekilde taşınmalıdır.

Sonuçları Karşılaştırmak

Source ve target response normalize edilerek karşılaştırılır. Timestamp veya ordering farkları hesaba katılmalıdır. Mismatch type sınıflandırılır. Büyük payload full loglanmamalıdır. Sample diff debugging'e yardım eder.

Mismatch Rate

Toplam shadow query içinde farklı sonuç oranı hesaplanır. Tenant veya query type bazında breakdown yapılabilir. Trend migration health'i gösterir. Cutover için maksimum oran tanımlanır. Kritik sorgular sıfır mismatch isteyebilir.

Shadow Traffic'in Performans Etkisi

Target ek read yükü alır. Application da ekstra outbound connection kullanır. Source doğrudan etkilenmese bile shared infrastructure etkilenebilir. Sampling oranı kontrollü artırılmalıdır. Target p99 latency normal traffic beklentisini karşılamalıdır.

Migration Validation İçin Hangi Metrikler Kullanılmalı?

Migration validation tek bir checksum sonucuna indirgenmemelidir. Missing row, extra row, value mismatch ve referential integrity ayrı metriklerdir. CDC lag target freshness'i gösterir. Shadow read mismatch uygulama davranışını test eder. Business metric difference teknik data doğruluğunu kullanıcı etkisiyle birleştirir.

Missing Row Count

Source'ta bulunup target'ta olmayan kayıt sayısıdır. Cutover için kritik metriktir. Table ve tenant bazında izlenebilir. Retry job eksikleri tamamlayabilir. Sıfır veya belirlenmiş tolerans hedeflenmelidir.

Extra Row Count

Target'ta olup source'ta bulunmayan kayıtları gösterir. Dual write veya retry duplicate sorunu olabilir. Soft delete farkı da sebep olabilir. Root cause sınıflandırılmalıdır. Unexpected extra row cutover'ı durdurabilir.

Value Mismatch Rate

Aynı primary key için farklı değer taşıyan kayıt oranıdır. Conversion bug veya CDC ordering problemi gösterebilir. Kolon bazında breakdown yararlıdır. Business critical field ayrı threshold kullanabilir. Trend sıfıra yaklaşmalıdır.

Referential Integrity Errors

Target relation'larındaki orphan veya invalid constraint sayısıdır. Schema conversion hatasını gösterebilir. Migration script repair yapabilir. Constraint enable öncesi sıfırlanmalıdır. Error örnekleri audit için saklanmalıdır.

CDC Lag

Target'ın source change stream'inden ne kadar geride olduğunu gösterir. Data equality testinin freshness boyutudur. Lag yüksekken mismatch doğal olarak artabilir. Validation window aynı position'a göre yapılmalıdır. Cutover gate olarak kullanılır.

Read Mismatch Rate

Shadow read response farklarını ölçer. Query result ordering normalize edilmelidir. Business response seviyesinde karşılaştırma yapılabilir. Database row equality'den daha güçlü signal olabilir. Canary cutover öncesi uzun süre izlenmelidir.

Business Metric Difference

Revenue total, order count veya active user gibi metrikler iki sistemde hesaplanır. Küçük row farkının business etkisi büyük olabilir. Domain owner threshold belirlemelidir. Migration dashboard teknik ve business metric'i birlikte göstermelidir. Final reconciliation için de kullanılır.

Sequence ve Auto-Increment Değerleri Nasıl Taşınır?

Data migration tamamlandığında identity üreticilerinin target state'i mutlaka doğrulanmalıdır. PostgreSQL sequence veya MySQL AUTO_INCREMENT değeri mevcut en yüksek ID'nin gerisinde kalırsa collision oluşabilir. Dual write sırasında iki bağımsız ID generator daha büyük risk yaratır. Tek aktif writer prensibi korunmalıdır. Cutover checklist sequence doğrulamasını açık madde olarak içermelidir.

PostgreSQL Sequence

PostgreSQL sequence tablo satırlarından bağımsız object'tir. Data copy sequence state'i otomatik taşımayabilir. Target current value max ID ile karşılaştırılmalıdır. setval benzeri mekanizma kontrollü kullanılabilir. Concurrent write sırasında race önlenmelidir.

MySQL AUTO_INCREMENT

AUTO_INCREMENT target table için doğru başlangıç değerinde olmalıdır. Full load sonrasında engine state kontrol edilir. Multi-writer setup collision riski yaratabilir. Writer switch sırasında tek source korunmalıdır. Heterogeneous migration'da ID generator modeli ayrıca tasarlanmalıdır.

Hedefte Son Değeri Kontrol Etmek

Target generator değeri mevcut maksimum ID'nin üzerinde olmalıdır. Bu kontrol cutover hemen öncesi yapılır. CDC son write'lar devam ettiği için erken kontrol yeterli değildir. Script otomatik doğrulama yapabilir. Hata go/no-go kriterini durdurmalıdır.

Cutover Sonrası ID Collision'ı Önlemek

Source ve target aynı anda yeni ID üretmemelidir. Fencing veya write routing ile source read-only yapılır. Generator target'ta güvenli değere alınır. İlk write'lar dikkatle izlenir. Unique violation alarmı migration sonrası yüksek öncelikli olmalıdır.

Timezone, Encoding ve Collation Migration Riskleri

Veri migration'ında satır sayısı eşit olsa bile encoding, collation ve timezone farkları kullanıcı açısından ciddi hata üretebilir. UTF-8 dönüşümü bozuk karakter yaratabilir. Case sensitivity unique constraint sonuçlarını değiştirebilir. Timestamp conversion yanlış saat gösterebilir. Decimal precision finansal hesaplarda özel dikkat gerektirir.

UTF-8

Source ve target character encoding aynı görünse bile gerçek data içinde invalid byte bulunabilir. Conversion error'ları önceden taranmalıdır. Emoji ve çok dilli karakterler test edilmelidir. Application driver encoding ayarı doğrulanmalıdır. Validation sample yalnızca ASCII veriden seçilmemelidir.

Case Sensitivity

Collation case-sensitive veya case-insensitive davranabilir. "User" ve "user" target'ta aynı kabul edilebilir. Unique constraint conflict oluşabilir. Search sonuçları değişebilir. Business beklentisi migration öncesi netleştirilmelidir.

Sorting

Collation değişikliği ORDER BY sonucunu değiştirebilir. Pagination cursor behavior bozulabilir. Locale-specific karakter sırası test edilmelidir. Index order da farklı olabilir. Shadow read ordering normalization dikkatle yapılmalıdır.

Timestamp

Timestamp type semantics engine'ler arasında farklı olabilir. Local timezone ile saklanan değerler risklidir. Precision milisaniye veya mikrosaniye seviyesinde değişebilir. Conversion deterministic olmalıdır. Historical edge case'ler test edilmelidir.

UTC

Database ve application internal timestamp için UTC kullanmak migration riskini azaltır. Display timezone client tarafında uygulanabilir. Source'taki local time kayıtları migration öncesi analiz edilmelidir. DST değişimleri edge case oluşturur. Cutover farklı region'larda test edilmelidir.

Decimal Precision

Para ve ölçüm alanlarında precision ve scale birebir korunmalıdır. Float dönüşümü kullanılmamalıdır. Rounding rule business tarafından belirlenmelidir. Aggregate totals source ve target arasında karşılaştırılmalıdır. Precision loss sıfır toleranslı olabilir.

Stored Procedure, Function ve Trigger Migration

Database içindeki procedural logic heterogeneous migration'ın en riskli alanlarından biridir. Source'taki tüm procedure, function ve trigger envantere alınmalıdır. Hedef database syntax ve semantics ile birebir uyumlu olmayabilir. Conversion sonrası yalnızca compile olması yeterli değildir. Business output ve performance ayrıca test edilmelidir.

Kaynak Envanteri

Production'da kullanılan tüm stored object'ler listelenir. Kullanılmayan object'ler belirlenir. Application dependency haritası çıkarılır. Trigger side effect'leri özellikle belgelenir. Migration kapsamı bu envanter üzerinden yönetilir.

Hedef Database Uyumluluğu

Her function ve procedure için target eşdeğeri değerlendirilir. Unsupported feature application layer'a taşınabilir. Transaction semantics farklı olabilir. Error handling behavior test edilmelidir. Permission modeli yeniden oluşturulabilir.

Syntax Conversion

Procedure dili target syntax'ına dönüştürülür. Otomatik conversion ilk başlangıç sağlayabilir. Manual review gerekir. Dynamic SQL ve exception block'ları risklidir. Test coverage oluşturulmalıdır.

Semantic Validation

Aynı input source ve target function'a verilerek sonuç karşılaştırılır. Side effect tabloları da kontrol edilir. Null ve edge case'ler test edilir. Transaction rollback behavior doğrulanır. Compile success semantic correctness değildir.

Performance Test

Yeni engine aynı procedure'ı farklı execution plan ile çalıştırabilir. p95 ve p99 latency ölçülmelidir. Index ihtiyacı değişebilir. Bulk işlem throughput'u karşılaştırılır. Target tuning migration kapsamına dahil edilmelidir.

Blue-Green Database Migration Nedir?

Blue-green database migration mevcut database ile yeni target database'i bir süre yan yana çalıştırır. Blue production source, green yeni hedef olarak düşünülür. İki sistem continuous synchronization ile güncel tutulur. Read trafiği önce green üzerinde doğrulanabilir. Write cutover en son yapılır ve blue rollback için belirli süre korunur.

Blue Database

Blue mevcut production source of truth'tur. Migration başlangıcında tüm write burada devam eder. CDC değişiklikleri green'e taşır. Kullanıcı trafiği normal şekilde çalışır. Cutover sonrası blue read-only yapılabilir.

Green Database

Green yeni schema veya infrastructure üzerinde hazırlanır. Full load ile historical data taşınır. CDC ile güncel tutulur. Shadow read ve canary trafik burada test edilir. Writer switch için validation gate'i geçmelidir.

Continuous Synchronization

Blue üzerindeki her değişiklik green'e aktarılır. CDC veya güvenilir event pipeline kullanılabilir. Lag sürekli izlenir. Schema compatibility korunur. Cutover öncesi target source'a yetişmelidir.

Gradual Read Cutover

Önce internal veya küçük kullanıcı grubu green'den okumaya başlar. Error ve latency karşılaştırılır. Traffic oranı kademeli yükseltilir. Write hâlâ blue'da olabilir. Read-after-write consistency doğru yönetilmelidir.

Write Cutover

Green validation sonrası aktif writer olur. Blue write kabul etmeyi bırakmalıdır. Fencing uygulanır. Application connection pool green'e yönlendirilir. İlk write'lar özel dashboard ile izlenir.

Eski Database'i Rollback İçin Tutmak

Blue cutover sonrasında hemen silinmemelidir. Read-only grace period rollback kolaylığı sağlar. Reverse replication gerekebilir. Final reconciliation tamamlanır. Decommission kararı stability window sonunda verilir.

Canary Database Cutover Nasıl Yapılır?

Canary cutover yeni database'i önce küçük kullanıcı grubuyla test eder. Internal users en güvenli başlangıç grubudur. Ardından trafik yüzde bir, yüzde on ve daha yüksek oranlara çıkarılır. Her aşamada error, latency ve data mismatch quality gate'i kontrol edilir. Sorun görüldüğünde trafik büyütülmeden geri alınır.

Internal Users

İlk target trafik ekip veya test hesaplarından gelebilir. Gerçek production code path kullanılır. Hata kullanıcı kitlesine yayılmadan görülür. Logging daha ayrıntılı tutulabilir. Kritik business flow manuel test edilir.

%1 Trafik

Küçük gerçek kullanıcı grubu target'a yönlendirilir. Error rate baseline ile karşılaştırılır. Query latency ölçülür. Mismatch alert izlenir. Belirli stability süresi geçmeden oran artırılmaz.

%10 Trafik

Target daha gerçekçi concurrency görür. Connection pool ve cache behavior ortaya çıkar. Hot query pattern gözlenebilir. CDC source write pattern'ini taşımaya devam eder. Quality gate tekrar uygulanır.

%50 Trafik

Target ciddi production yükü taşır. Capacity sizing doğrulanır. Tail latency ve connection count yakından izlenir. Source hâlâ rollback seçeneği sunar. Writer switch planı son kez kontrol edilir.

%100 Trafik

Tüm read veya belirlenmiş traffic target'a geçer. Stabilite süresi başlar. Source kullanımının gerçekten azaldığı gözlemlenir. Writer cutover ayrı aşama olabilir. Decommission henüz yapılmaz.

Her Aşamada Quality Gate

Her traffic artışı otomatik veya manuel gate'e bağlı olmalıdır. Error, p99 ve mismatch threshold kontrol edilir. CDC lag artıyorsa rollout durabilir. Business success metric ayrıca izlenir. Hedef ölçütleri karşılamıyorsa bir sonraki aşamaya geçilmez.

Feature Flag Migration'da Nasıl Kullanılır?

Feature flag migration sırasında routing davranışını deployment'dan bağımsız yönetmeyi sağlar. Read ve write yolları ayrı flag ile kontrol edilebilir. Tenant veya kullanıcı grubu bazında target seçilebilir. Hata görüldüğünde hızlı rollback yapılabilir. Flag logic kalıcı infrastructure configuration yerine geçmemelidir.

Read Routing

Read request source veya target database'e flag ile yönlendirilebilir. Canary rollout kolaylaşır. Critical query farklı flag kullanabilir. Read-after-write session state unutulmamalıdır. Metric route seçimini göstermelidir.

Write Routing

Writer switch daha riskli olduğu için ayrı flag kullanılmalıdır. Aynı anda yalnızca tek aktif writer bulunmalıdır. Flag değişimi atomic olmalıdır. Stale application config risklidir. Fencing database seviyesinde de uygulanmalıdır.

Tenant Bazlı Flag

Multi-tenant uygulamada belirli tenant target'a taşınabilir. Büyük tenant ayrı izlenebilir. Tenant rollback diğer müşterileri etkilemez. Routing directory flag state ile uyumlu tutulmalıdır. Migration batch kolay yönetilir.

User Cohort

Kullanıcı grupları feature cohort üzerinden ayrılabilir. Internal, beta veya region bazlı rollout yapılabilir. Statistical comparison kolaylaşır. Session sırasında database route sık değişmemelidir. Cohort assignment stabil olmalıdır.

Hızlı Rollback

Flag target traffic'i saniyeler içinde source'a çevirebilir. Application redeploy gerekmez. Data rollback ayrıca düşünülmelidir. Writer switch sonrası reverse sync yoksa yalnız routing rollback yeterli olmayabilir. Bu sınır runbook'ta açıkça yazılmalıdır.

Read Cutover ve Write Cutover Hangi Sırayla Yapılmalı?

Çoğu migration'da read traffic'i önce target'a taşımak daha güvenlidir. Source writer olarak kalırken target query performansı gerçek kullanıcı yükünde doğrulanabilir. CDC source değişikliklerini target'a taşımaya devam eder. Read stability kanıtlandıktan sonra writer switch yapılır. Aynı anda iki aktif writer oluşturmamak temel kuraldır.

Reads'i Önce Taşımak

Read operation data state'i değiştirmez. Bu nedenle rollback daha kolaydır. Target query plan ve latency production load ile test edilir. Shadow read'den gerçek canary read'e geçiş yapılır. Writer source'ta kalır.

Writes'i Kaynakta Tutmak

Cutover başlangıcında source canonical writer olarak kalır. CDC target'ı güncel tutar. Data ownership belirsizleşmez. Target probleminde read traffic source'a dönebilir. Reverse CDC henüz gerekmez.

Hedef Read Performansını Doğrulamak

p95 ve p99 query latency izlenir. Connection pool ve cache behavior gözlenir. Query errors source baseline ile karşılaştırılır. CPU ve I/O kapasitesi doğrulanır. Performance gate geçmeden writer taşınmaz.

Son Aşamada Writer'ı Taşımak

Target data güncel olduğunda writer switch planlanır. Source yeni write kabul etmeyi bırakır. Son replication position kontrol edilir. Target writer aktif edilir. İlk transaction'lar özel olarak izlenir.

Tek Aktif Writer Prensibi

Migration boyunca canonical writer her an açıkça belirlenmelidir. İki database'in bağımsız write kabul etmesi divergence yaratabilir. Fencing bunu teknik olarak engeller. Routing config tek başına yeterli güvence olmayabilir. Write ownership audit log'a kaydedilmelidir.

Split-Brain Nasıl Önlenir?

Split-brain migration sırasında source ve target database'in aynı anda canonical writer haline gelmesidir. Bu durumda aynı entity iki farklı state alabilir. Single writer ve fencing en güçlü korumadır. Traffic routing tutarlı biçimde güncellenmelidir. Reverse replication kullanılıyorsa loop ve conflict riski ayrıca yönetilmelidir.

İki Database'in Aynı Anda Primary Olma Riski

Cutover sırasında stale application instance source'a write gönderebilir. Aynı anda yeni instance target'a write yapabilir. Data divergence oluşur. Connection pool uzun ömürlü ise risk büyür. Source write permission kesilebilir.

Single Writer

Her anda yalnızca bir database business write kabul eder. Ownership state merkezi olarak tutulabilir. Target activate edilmeden önce source fenced edilir. Failback sırasında sıra ters uygulanır. Bu prensip migration consistency'sini basitleştirir.

Fencing

Source application credential'ının write permission'ı kaldırılabilir. Proxy eski backend'e write route etmez. Generation token kullanılabilir. Eski connection'ların etkisi test edilmelidir. Fencing rollback procedure ile uyumlu olmalıdır.

Traffic Routing

Application endpoint'leri tek control plane üzerinden güncellenmelidir. Dağınık config değişiklikleri split routing yaratabilir. Feature flag veya proxy merkezi çözüm sunar. Route state observability içinde görünmelidir. Stale instance detection yapılmalıdır.

Reverse Replication Riskleri

Target'tan source'a reverse CDC rollback kolaylığı sağlayabilir. Aynı değişikliğin tekrar target'a dönmesi loop yaratmamalıdır. Conflict resolution açık olmalıdır. Replication direction state'i loglanmalıdır. Geçiş süresi kısa tutulmalıdır.

Cutover Runbook Nasıl Hazırlanır?

Cutover runbook migration günündeki tüm kritik adımları sıralı ve ölçülebilir hale getirir. Görev sahipleri önceden belirlenir. Go/no-go kriterleri ve rollback trigger açıkça yazılır. Validation ve iletişim adımları teknik işlemler kadar önemlidir. Runbook migration game day sırasında gerçek kişilerle prova edilmelidir.

Görev Sahipleri

Database, application, infrastructure ve incident sorumluları ayrı atanmalıdır. Her adımın tek owner'ı olmalıdır. Karar yetkisi belirsiz bırakılmamalıdır. İletişim kanalı önceden açılır. Yedek kişiler belirlenir.

Dakika Dakika Plan

Cutover sequence yaklaşık zaman çizelgesine yerleştirilir. Her adım beklenen süre taşır. Sapma belirli seviyeyi aşarsa plan yeniden değerlendirilir. Kritik pause noktaları işaretlenir. Bu plan gerçek dry-run süresine dayanmalıdır.

Pre-Cutover Checklist

Backup, CDC lag ve validation state kontrol edilir. Target kapasitesi doğrulanır. Long transaction ve maintenance job'lar incelenir. Feature flag hazır olmalıdır. Checklist tamamlanmadan go kararı verilmez.

Go/No-Go Criteria

Replication lag, mismatch ve error rate belirli sınır içinde olmalıdır. İnsan hissi yerine metric kullanılır. Tek kritik criterion başarısızsa cutover ertelenebilir. Business owner karar sürecine dahil edilir. Criteria migration başlamadan günler önce netleştirilmelidir.

Validation

Cutover öncesi ve sonrası validation çalıştırılır. Row count ve business metric karşılaştırılır. İlk write target üzerinde doğrulanır. Query latency kontrol edilir. Validation sonucu merkezi kanalda paylaşılır.

Rollback Trigger

Hangi error rate veya latency seviyesinde rollback yapılacağı yazılmalıdır. Data divergence özel trigger olabilir. Belirsiz "sorun olursa döneriz" yeterli değildir. Decision owner bellidir. Rollback süresi önceden test edilir.

İletişim Planı

Teknik ekip ve business stakeholder hangi aşamada bilgilendirileceğini bilmelidir. Incident kanalı ayrı tutulabilir. Kullanıcı etkisi oluşursa support ekibi bilgilendirilir. Status mesajı şablonları önceden hazırlanabilir. İletişim teknik karar hızını artırır.

Cutover Öncesi DNS Nasıl Hazırlanır?

Database endpoint değişimi DNS üzerinden yapılacaksa caching davranışı migration öncesi ele alınmalıdır. TTL cutover'dan hemen önce değil, yeterli süre önceden düşürülmelidir. Client ve işletim sistemi kendi DNS cache'ine sahip olabilir. Service discovery veya database proxy daha hızlı route değişimi sağlayabilir. Bazı sistemlerde DNS yerine configuration switch daha kontrollüdür.

DNS TTL Düşürme

TTL eski kaydın cache'de kalabileceği süreyi etkiler. Cutover'dan önce düşük değere alınmalıdır. Mevcut yüksek TTL'nin expire olması beklenir. Çok düşük TTL sürekli DNS load artırabilir. Migration sonrası normal değerine döndürülmelidir.

DNS Cache

Driver veya operating system TTL'yi farklı yorumlayabilir. Connection pool mevcut socket'i DNS'den bağımsız kullanmaya devam eder. Bu nedenle yalnız DNS değişimi yeterli değildir. Client behavior test edilmelidir. Pool recycle planı hazırlanmalıdır.

Service Discovery

Application backend endpoint'i discovery service üzerinden öğrenebilir. Topology değişikliği daha hızlı yayılabilir. Discovery control plane high available olmalıdır. Cache invalidation yine önemlidir. Migration sırasında route state görünür tutulmalıdır.

Database Proxy

Application stable proxy endpoint'e bağlanabilir. Proxy backend database'i cutover sırasında değiştirebilir. Client DNS değişikliği yaşamaz. Existing backend connection drain edilebilir. Proxy'nin kendi HA tasarımı güçlü olmalıdır.

DNS Yerine Configuration Switch Kullanımı

Connection string merkezi config veya feature flag üzerinden değiştirilebilir. Rollout daha kontrollü yapılabilir. Application instance'ların config refresh davranışı bilinmelidir. Stale config split routing yaratabilir. Version veya generation number kullanılabilir.

Connection Pool Migration Sırasında Nasıl Yönetilir?

Connection pool cutover sırasında en sık unutulan application bileşenlerinden biridir. Endpoint değişse bile eski connection'lar saatlerce source database'e bağlı kalabilir. Pool drain ve maksimum connection lifetime bu riski azaltır. Prepared statement cache target schema ile uyumsuz olabilir. Connection storm oluşmaması için reconnect işlemi kademeli yapılmalıdır.

Eski Connection'ların Yaşam Süresi

Long-lived connection source'a bağlı kalmaya devam eder. DNS veya config değişikliği mevcut socket'i etkilemez. Maximum lifetime cutover öncesi düşürülebilir. Idle connection'lar daha hızlı kapatılabilir. Connection age metric yararlıdır.

Pool Drain

Application yeni request'leri eski connection'a vermeyi durdurur. In-flight transaction tamamlanır. Daha sonra connection kapatılır. Hard kill transaction kaybı yaratabilir. Drain süresi runbook'ta yer almalıdır.

Maximum Connection Lifetime

Pool connection'larının belirli süreden sonra yenilenmesi sağlanabilir. Cutover öncesi değer geçici olarak azaltılabilir. Tüm instance aynı anda reconnect olmamalıdır. Jitter uygulanabilir. Migration sonrası normal değere dönülür.

Connection String Rotation

Yeni target connection string merkezi secret veya config üzerinden dağıtılır. Eski credential kısa süre rollback için tutulabilir. Versionlu secret faydalıdır. Stale application instance tespit edilmelidir. Credential rotation audit edilmelidir.

Prepared Statement Cache

Prepared statement source schema'ya göre oluşturulmuş olabilir. Target geçişinde invalid plan hatası oluşabilir. Pool recycle cache'i temizleyebilir. Driver-specific behavior test edilmelidir. Heterogeneous migration'da daha fazla risk vardır.

Connection Storm'u Önlemek

Binlerce instance aynı anda yeni connection açmamalıdır. Exponential backoff ve jitter kullanılabilir. Proxy backend connection'ları stabilize edebilir. Target connection limitinde headroom bulunmalıdır. Reconnect load test yapılmalıdır.

Database Proxy Cutover'ı Kolaylaştırabilir mi?

Database proxy application ile backend database arasına sabit bağlantı katmanı koyabilir. Application endpoint'i değişmeden backend source'tan target'a çevrilebilir. Connection multiplexing connection storm riskini azaltabilir. Health check target hazır olmadan trafik verilmesini engeller. Proxy'nin kendisi yeni single point of failure olmamalıdır.

Stable Application Endpoint

Application her zaman aynı proxy adresine bağlanır. Backend topology değişikliğini bilmek zorunda değildir. Connection string rollout riski azalır. Driver configuration daha basit kalır. Proxy latency sürekli izlenmelidir.

Backend Database Değişimi

Proxy source connection'larını drain edip target connection açabilir. Route kademeli değiştirilebilir. Read ve write backend ayrı yönetilebilir. Fencing ile eski writer kapatılır. Backend state dashboard'da görünmelidir.

Connection Multiplexing

Çok sayıda client connection daha az backend connection üzerinden kullanılabilir. Database connection load'u azalır. Session-specific özellikler multiplexing'i sınırlayabilir. Transaction semantics doğru korunmalıdır. Proxy kapasitesi benchmark edilmelidir.

Health Checks

Target yalnız port açık olduğu için sağlıklı kabul edilmemelidir. Query latency ve replication state kontrol edilebilir. Write readiness ayrı health signal olabilir. Failure halinde route source'a dönebilir. Check interval RTO hedefiyle uyumlu olmalıdır.

Proxy'nin Single Point of Failure Olmaması

Proxy birden fazla instance olarak çalışmalıdır. Load balancer veya service discovery kullanılabilir. Config state replicated olmalıdır. Bir instance kaybı database erişimini kesmemelidir. Proxy failure chaos test kapsamına alınmalıdır.

Migration Sırasında Monitoring

Migration sırasında source, target ve application aynı dashboard üzerinde izlenmelidir. Replication lag veri freshness'i gösterir. CPU, memory ve disk I/O capacity baskısını gösterir. Connection count ve lock wait database erişim sorunlarını görünür kılar. Query latency ve error rate kullanıcı etkisinin en doğrudan teknik göstergeleridir.

Replication Lag

Target'ın source'tan ne kadar geride olduğu sürekli ölçülür. Lag trendi cutover hazırlığını gösterir. Ani artış full load veya target saturation kaynaklı olabilir. Threshold aşılırsa migration throttle edilir. Final writer switch düşük lag gerektirir.

Database CPU

Source full load read, target ise copy ve CDC write nedeniyle CPU kullanır. Peak seviyeler izlenmelidir. Saturation kullanıcı query latency'sini artırır. Worker concurrency düşürülebilir. Cutover sonrası target steady-state CPU ayrıca ölçülür.

Memory

Large sort ve copy process memory baskısı yaratabilir. Connection count memory kullanımını artırır. Cache warmup target'ta farklı davranış oluşturabilir. Swap kullanımı riskli signal olabilir. Migration worker memory'si database'den ayrı izlenmelidir.

Disk I/O

Full load source read ve target write I/O üretir. Index build ek yük ekler. Disk latency yükselirse query SLO bozulur. Backfill throttle I/O metriğine bağlanabilir. Target storage throughput doğru boyutlandırılmalıdır.

Connection Count

Shadow read ve dual write connection sayısını artırabilir. Source ve target ayrı izlenmelidir. Pool saturation application bekleme süresi yaratır. Database max connection headroom korunmalıdır. Proxy kullanılıyorsa backend ve client connection ayrı takip edilir.

Lock Wait

Schema migration lock bekleme süresi kullanıcı etkisini gösterir. DDL query sonsuza kadar beklememelidir. Blocker transaction tespit edilmelidir. lock_timeout safety guard sağlar. Lock wait spike rollout'u durdurabilir.

Query Latency

Read ve write p95/p99 ayrı izlenmelidir. Source ve target karşılaştırılabilir. Cache warmup ilk dakikalarda fark yaratabilir. Cross-region target network latency ekleyebilir. Quality gate latency threshold kullanmalıdır.

Error Rate

Database timeout, connection error ve constraint violation ayrı kategorilenmelidir. Application 5xx ile birlikte incelenir. Target error baseline source'tan kötü olmamalıdır. Spike canary rollout'u durdurur. Error sample debugging için saklanır.

Application Metrikleri Neden Database Metrikleri Kadar Önemlidir?

Database dashboard yeşil görünürken kullanıcı işlemleri başarısız olabilir. Connection pool, cache veya application retry davranışı database metriğinde görünmeyebilir. HTTP 5xx, p95 ve p99 latency kullanıcı etkisini doğrudan gösterir. Checkout, login ve business transaction success daha da güçlü sinyaldir. Backend runtime sağlığını izlerken memory ve process davranışını değerlendirmek için https://www.diyarbakiryazilim.com.tr/posts/kurumsal-node-js-projelerinde-bellek-memory-yonetimi içeriği de tamamlayıcı bir bakış sunabilir.

HTTP 5xx

Database bağlantı sorunu application 5xx olarak kullanıcıya yansıyabilir. Migration öncesi normal baseline bilinmelidir. Canary grubunda ayrı ölçüm yapılabilir. Retry bazı transient hataları gizleyebilir. Sustained artış rollback trigger olabilir.

P95 Latency

Request'lerin yüzde doksan beşinin altında kaldığı latency değeri kullanıcı çoğunluğunu gösterir. Database route değişimi bu değeri etkileyebilir. Network ve pool wait dahil edilir. Source ve target cohort karşılaştırılır. Threshold migration criteria içinde bulunmalıdır.

P99 Latency

P99 tail behavior'u gösterir. Connection reconnect veya yavaş query ilk burada görünür. Ortalama değer normal kalabilir. High-value transaction ayrıca ölçülebilir. Cutover oranı p99 bozuluyorsa artırılmamalıdır.

Checkout Success

E-ticaret benzeri uygulamalarda checkout başarı oranı doğrudan business metric'tir. Database error küçük görünse bile revenue etkisi büyük olabilir. Canary target cohort karşılaştırılabilir. Payment idempotency migration sırasında önemlidir. Bu metric teknik SLO ile birlikte izlenmelidir.

Login Success

Authentication query veya session store target database'e bağlı olabilir. Login failure kullanıcıyı tamamen sistem dışında bırakır. Permission data freshness önemlidir. Read replica veya target consistency test edilmelidir. Login success cutover gate olarak kullanılabilir.

Business Transaction Success

Sipariş, kayıt veya para transferi gibi temel işlemler ayrı metric olmalıdır. HTTP 200 her zaman business success değildir. Database constraint veya async process sonucu etkileyebilir. Source ve target cohort karşılaştırılmalıdır. Migration teknik başarıyı business sonuçla bağlamalıdır.

Migration Dashboard'da Neler Olmalıdır?

Migration dashboard teknik ekiplerin tek ekrandan ilerleme ve risk görmesini sağlamalıdır. Full load progress ve rows migrated temel ilerleme metrikleridir. CDC lag data freshness'i gösterir. Validation mismatch ve error count kalite sinyalidir. Database load ile cutover traffic percentage aynı zaman çizelgesinde izlenmelidir.

Full Load Progress

Toplam data'nın ne kadarının target'a kopyalandığını gösterir. Table bazında breakdown yapılabilir. Tahmini completion trend olarak hesaplanabilir. Hız düşüşü network veya target load problemi gösterebilir. Progress yalnız row count üzerinden değerlendirilmemelidir.

CDC Lag

Source change stream ile target apply arasındaki fark görünür olmalıdır. Time ve byte lag birlikte gösterilebilir. Cutover threshold çizgisi dashboard'da bulunabilir. Backfill hız değişimiyle korelasyon görülebilir. Ani spike alarm üretmelidir.

Rows Migrated

Başarıyla taşınan row sayısı table bazında izlenir. Retry veya duplicate count ayrıca tutulmalıdır. Row size farklı olduğu için byte metriği de eklenebilir. Missing row validation ile ilişkilendirilir. Progress reset olmamalıdır.

Error Count

Migration worker, CDC ve target database hataları ayrı sayılmalıdır. Error rate ve total count birlikte gösterilir. Permanent ve retryable error sınıflandırılır. DLQ sayısı görünür olmalıdır. Kritik hata cutover'ı engeller.

Validation Mismatch

Source-target farklarının sayısı ve oranı izlenir. Table ve tenant bazında breakdown faydalıdır. Trend zamanla düşmelidir. New mismatch artışı CDC problemi gösterebilir. Critical table için threshold sıfır olabilir.

Database Load

CPU, I/O, connection ve lock wait migration hızının güvenli olup olmadığını gösterir. Source ve target yan yana görüntülenir. Replica lag aynı grafikte olabilir. Throttling trigger'ları işaretlenir. Kullanıcı SLO her zaman önceliklidir.

Cutover Traffic Percentage

Target'a yönlenen read ve write yüzdesi ayrı gösterilmelidir. Canary rollout hangi aşamada olduğu anlaşılır. Error metric aynı zaman çizelgesine yerleştirilir. Rollback sonrası oran düşüşü görülür. Route source'u trace metadata'sında da bulunabilir.

Rollback Planı Nasıl Tasarlanır?

Rollback migration başlamadan önce tasarlanmalıdır. Application rollback, read routing rollback ve write routing rollback farklı işlemlerdir. Writer target'a geçtikten sonra data rollback daha zor hale gelir. Reverse CDC veya feature flag geçişi kolaylaştırabilir. Her rollback türünün data consistency etkisi runbook'ta açıkça belirtilmelidir.

Application Rollback

Yeni application version eski schema ile çalışabilmelidir. Expand-and-contract bu uyumluluğu sağlar. Deployment platformu önceki version'a hızlı dönebilmelidir. New-only write format varsa dönüşüm gerekir. Rollback staging'de test edilmelidir.

Read Routing Rollback

Read traffic target'tan source'a kolayca döndürülebilir. Feature flag veya proxy kullanılır. Source hâlâ güncel olduğu sürece düşük risklidir. Connection pool yeni route'a adapte olmalıdır. Read rollback saniyeler içinde yapılabilir.

Write Routing Rollback

Writer target'a geçtikten sonra source'un güncel kalması gerekir. Reverse CDC yoksa yeni target write'ları source'ta bulunmaz. Sadece endpoint değiştirmek data kaybına yol açabilir. Rollback öncesi data direction doğrulanmalıdır. Single writer prensibi tekrar uygulanır.

Data Rollback

Hedefte oluşan yeni verinin source'a taşınması gerekebilir. Transaction ordering korunmalıdır. Duplicate event idempotent işlenmelidir. Schema farkı conversion gerektirebilir. Bu işlem routing rollback'tan daha pahalıdır.

Reverse CDC

Cutover sonrası target change stream source'a aktarılabilir. Rollback penceresinde iki sistem yakın kalır. Replication loop engellenmelidir. Direction metadata açık tutulmalıdır. Stability sonrası reverse CDC kapatılır.

Feature Flag ile Rollback

Read route flag ile hızlı değiştirilebilir. Write route için fencing birlikte yapılmalıdır. Flag stale instance'larda doğru yenilenmelidir. Data synchronization state kontrol edilir. Flag rollback'in tamamı değildir, yalnız routing aracıdır.

Point of No Return Nedir?

Point of no return migration'ın güvenli ve hızlı rollback seçeneğinin ciddi biçimde azaldığı aşamadır. Destructive schema değişiklikleri bu noktaya yaklaştırır. Eski kolonun silinmesi veya source database'in kapatılması geri dönüş maliyetini yükseltir. Reverse replication olmadan target'ta write başlamak da risklidir. Bu noktayı mümkün olduğunca geç tutmak migration güvenliğini artırır.

Destructive Schema Change

DROP veya irreversible type conversion eski application'ı tekrar çalıştırmayı zorlaştırır. Backup restore gerekebilir. Contract aşaması bu yüzden en sona bırakılır. Dependency scan tamamlanmalıdır. Change record point-of-no-return olarak işaretlenebilir.

Eski Kolonun Silinmesi

Drop edilen kolon rollback için data kaybı yaratabilir. Backup restore zaman alır. Eski application alanı bekliyorsa çalışamaz. Usage metric sıfır olmalıdır. Stability window dolmadan drop edilmemelidir.

Source Database'in Decommission Edilmesi

Source kapatıldığında hızlı route rollback mümkün olmaz. Backup restore yeni infrastructure gerektirebilir. Final reconciliation bitmiş olmalıdır. Audit ve retention tamamlanmalıdır. Decommission ayrı change window'da yapılmalıdır.

Reverse Replication Olmadan Yeni DB'ye Write Başlamak

Target yeni canonical write almaya başlar. Source artık geride kalır. Birkaç dakika sonra bile rollback data transferi gerektirebilir. Reverse CDC veya dual sync bunu azaltır. Point of no return bu nedenle writer switch'e çok yakın olabilir.

Bu Noktayı Mümkün Olduğunca Geciktirmek

Eski schema ve source bir süre korunmalıdır. Compatibility window açık tutulur. Destructive cleanup migration başarısından günler sonra yapılabilir. Storage maliyeti rollback güvenliğinin bedelidir. Kritik sistemlerde bu bedel çoğu zaman değerlidir.

Rollback mı Roll-Forward mı?

Her migration hatasında rollback en doğru çözüm değildir. Küçük application bug hızlı hotfix ile çözülebilir. Data divergence veya temel schema incompatibility rollback gerektirebilir. Karar error impact, recovery süresi ve data state üzerinden verilmelidir. Önceden hazırlanmış decision matrix panik anında karar kalitesini artırır.

Hangi Hatalar Rollback Gerektirir?

Data loss veya ciddi consistency problemi rollback adayıdır. Target database temel capacity hedefini karşılamıyorsa geri dönüş gerekebilir. Widespread business transaction failure da güçlü sinyaldir. Security veya permission problemi bekletilmemelidir. Trigger threshold runbook'ta yazılı olmalıdır.

Hangi Hatalar Hotfix ile Çözülebilir?

Dar kapsamlı query bug veya düşük riskli display farkı roll-forward ile çözülebilir. Target data doğruysa rollback gereksiz risk yaratabilir. Fix hızlı ve güvenli uygulanabilmelidir. Feature flag problemi izole edebilir. Decision owner etkilenme alanını değerlendirmelidir.

Data Divergence

Source ve target farklı business state taşıyorsa önce divergence yönü anlaşılmalıdır. Yeni writer data'sı kaybedilmemelidir. Reconciliation veya reverse sync gerekebilir. Blind routing rollback tehlikelidir. Data owner karara dahil edilmelidir.

Schema Compatibility

Yeni application eski schema'ya dönebiliyor mu kontrol edilmelidir. Contract change yapılmışsa rollback zor olabilir. Expand stage compatibility sağlar. Destructive change sonrası roll-forward daha güvenli olabilir. Decision matrix bunu hesaba katmalıdır.

Decision Matrix

Hata türü, kullanıcı etkisi ve data riskine göre seçenekler önceden yazılır. Rollback time ve hotfix time karşılaştırılır. Data synchronization state kriterlerden biridir. Business owner belirli risk seviyesinde karar verir. Matrix game day sırasında prova edilmelidir.

Migration Sonrası Eski Database Hemen Kapatılmalı mı?

Eski database migration biter bitmez kapatılmamalıdır. Read-only grace period rollback ve reconciliation için değerli bir güvenlik alanı sağlar. Final backup ve audit tamamlanmalıdır. Application'ın source'a hâlâ connection açmadığı doğrulanmalıdır. Decommission window migration'dan ayrı planlanmalıdır.

Read-Only Grace Period

Source write kabul etmeyi bırakır ancak read için erişilebilir kalır. Debugging ve reconciliation kolaylaşır. Permission sınırlanmalıdır. Süre business riskine göre belirlenir. Reverse sync kullanılıyorsa state daha güncel olabilir.

Decommission Window

Source kapatma ayrı operasyon olarak planlanır. Migration günüyle aynı saate sıkıştırılmamalıdır. Stability metric gözden geçirilir. Stakeholder onayı alınır. Infrastructure resource daha sonra serbest bırakılır.

Audit

Kimlerin source'a eriştiği kontrol edilir. Migration sonrası unexpected query varsa araştırılır. Application dependency gözden kaçmış olabilir. Audit log belirli süre saklanır. Decommission öncesi erişim sıfıra yaklaşmalıdır.

Backup

Source son state için final backup alınabilir. Retention policy belirlenir. Restore testi migration öncesi zaten yapılmış olmalıdır. Backup encryption korunur. Decommission sonrası tek geri dönüş kaynağı olabilir.

Final Reconciliation

Source ve target son kez karşılaştırılır. Row count, checksum ve business total kontrol edilir. Missing transaction aranır. Sequence state doğrulanır. Fark kalmadığında decommission onayı verilir.

Kullanılmadığını Doğrulamak

Connection log source'a trafik gelip gelmediğini gösterir. DNS veya config dependency kalmış olabilir. Scheduled job'lar ayrıca kontrol edilmelidir. Monitoring birkaç gün gözlemleyebilir. Sıfır kullanım görülmeden source silinmemelidir.

Post-Migration Reconciliation

Post-migration reconciliation target database'in production source of truth olarak doğru state taşıdığını doğrular. Final row count hızlı kontrol sağlar. Checksums ve business totals daha güçlü güvence verir. Missing transaction ve referential integrity ayrıca incelenir. Sequence state de yeni write'ların güvenli devamı için kontrol edilmelidir.

Final Row Count

Tüm kritik tablolar source ve target arasında karşılaştırılır. Soft delete filtreleri aynı olmalıdır. Partition veya tenant bazında breakdown faydalıdır. Büyük tablo count süresi planlanmalıdır. Fark varsa root cause bulunmadan source silinmez.

Checksums

Chunk-level checksum data içeriğini karşılaştırır. Migration sonrası final snapshot üzerinde çalıştırılabilir. Mismatch chunk yeniden incelenir. Normalization determinist olmalıdır. Checksum raporu audit artifact olarak saklanabilir.

Business Totals

Order, payment veya account toplamları domain düzeyinde karşılaştırılır. Teknik row equality'nin ötesine geçer. Critical metric için sıfır fark istenebilir. Time window aynı olmalıdır. Business stakeholder sonucu doğrulayabilir.

Missing Transactions

Cutover çevresindeki transaction ID'ler iki sistemde aranır. CDC gap veya timeout nedeniyle eksik işlem bulunabilir. Application audit log yardımcı olur. Missing write repair edilmelidir. Kullanıcı etkisi ayrıca değerlendirilir.

Sequence Kontrolü

Target sequence son kullanılan ID'nin üzerinde olmalıdır. İlk production write'lar collision açısından izlenir. Multiple sequence varsa otomatik script kullanılabilir. Heterogeneous migration mapping kontrol edilir. Bu adım decommission öncesi tamamlanır.

Referential Integrity

Foreign key veya logical relationship taraması yapılır. Orphan kayıtlar raporlanır. Migration sırasında constraint geçici kapatıldıysa yeniden validate edilir. Business relation ayrıca kontrol edilebilir. Integrity error kalmadan migration closure verilmelidir.

AWS DMS ile Minimal Kesintili Migration

AWS DMS benzeri managed migration servisleri full load ve CDC yaklaşımını otomatikleştirmeye yardımcı olabilir. Source ve target endpoint'ler tanımlanır. Full load historical data'yı taşır. CDC source değişikliklerini target'a aktarmaya devam eder. Cutover yine application routing, validation ve rollback planı gerektirir.

Source Endpoint

Migration service source database'e gerekli izinlerle bağlanır. Network erişimi test edilmelidir. Read ve CDC permission minimum tutulur. SSL kullanımı doğrulanır. Connection test migration başlamadan geçmelidir.

Target Endpoint

Target database write kabul edecek şekilde hazırlanır. Schema mapping önceden doğrulanmalıdır. Connection limit ve throughput yeterli olmalıdır. Encryption ayarları kontrol edilir. Endpoint health migration dashboard'a eklenebilir.

Full Load

Existing data target'a toplu olarak taşınır. Table bazında parallelism ayarlanabilir. Büyük table progress izlenir. Source load korunmalıdır. Validation full load sonrası başlatılır.

Full Load + CDC

Historical copy ile ongoing changes birlikte yönetilir. Migration boyunca source production writer olmaya devam eder. Target giderek source'a yaklaşır. CDC lag cutover gate'tir. Bu model uzun migration penceresi için uygundur.

CDC Only

Target data başka yöntemle önceden yüklenmiş olabilir. Bu durumda yalnız ongoing change replication kullanılabilir. Başlangıç position doğru seçilmelidir. Data baseline aynı olmalıdır. Validation yine zorunludur.

Replication Lag

Managed service'in sunduğu lag metriği izlenmelidir. Target apply kapasitesi sorunu görülebilir. Large transaction spike yaratabilir. Cutover lag düşük seviyeye gelmeden yapılmamalıdır. Alert threshold business RPO ile uyumlu olmalıdır.

Cutover

Target readiness doğrulandıktan sonra application route değiştirilir. Source writer fenced edilir. Connection pool target'a taşınır. Validation ve business metric kontrol edilir. Managed migration tool cutover'ın yalnız data sync bölümünü çözer.

Google Cloud Database Migration Service ile Migration

Google Cloud Database Migration Service benzeri managed çözümler supported source-target kombinasyonlarında continuous migration sağlayabilir. Initial snapshot historical data'yı hedefe taşır. CDC ongoing değişiklikleri aktarır. Destination readiness ve application compatibility cutover öncesi ayrıca doğrulanmalıdır. Homogeneous ve heterogeneous migration yetenekleri servis ve engine desteğine göre değerlendirilmelidir.

Continuous Migration

Source production'da çalışmaya devam ederken target güncel tutulur. Replication lag izlenir. Uzun migration penceresi mümkün olur. Application cutover bağımsız planlanabilir. Source log retention yeterli olmalıdır.

Initial Snapshot

Existing dataset başlangıç kopyası target'a taşınır. Snapshot consistency korunmalıdır. Büyük database migration süresini uzatabilir. Network throughput ölçülmelidir. Copy sırasında source write devam eder.

CDC

Snapshot sonrasındaki değişiklikler transaction log üzerinden aktarılabilir. Target apply rate izlenir. DDL support sınırlamaları incelenmelidir. Lag cutover gate olarak kullanılır. Error event'leri temizlenmelidir.

Destination Readiness

Target schema, user ve connection ayarları hazır olmalıdır. Query performance test edilir. Index ve extension uyumu kontrol edilir. Application shadow read yapılabilir. Destination yalnız data varlığıyla hazır sayılmaz.

Finalize Migration

Target source'a yetiştiğinde finalization planlanır. Application writer target'a yönlendirilir. Source write kapatılır. Data validation tekrarlanır. Rollback window korunur.

Homogeneous vs Heterogeneous

Managed service support matrix engine kombinasyonuna göre değişebilir. Homogeneous migration genellikle daha doğrudan replication sunar. Heterogeneous geçiş schema conversion gerektirebilir. Unsupported object'ler manual taşınır. Product documentation kullanılan kombinasyon için kontrol edilmelidir.

Debezium ile CDC Pipeline

Debezium database transaction log'larını event stream'e dönüştüren CDC yaklaşımı sunar. PostgreSQL ve MySQL connector'ları farklı log mekanizmalarını takip eder. Kafka gibi event platformu change event'leri taşıyabilir. Schema history ve offset recovery açısından önemlidir. Replay imkanı migration ve downstream processing için güçlü avantaj sağlar.

PostgreSQL Connector

PostgreSQL connector logical decoding üzerinden değişiklik okuyabilir. Replication slot kullanımı source disk riskini etkiler. Publication scope doğru seçilmelidir. LSN progress takip edilir. Connector stop süresi retention ile uyumlu olmalıdır.

MySQL Connector

MySQL connector binlog üzerinden row değişikliklerini takip eder. Binlog retention yeterli olmalıdır. GTID topology değişikliğinde yardımcı olabilir. Schema change event'leri ayrıca ele alınır. Connector credential least privilege olmalıdır.

Kafka

Change event'leri Kafka topic'lerine yazılabilir. Partition key ordering'i etkiler. Retention replay penceresini belirler. Broker kapasitesi source write throughput'unu taşımalıdır. Migration sırasında queue lag ayrıca izlenir.

Change Events

Insert, update ve delete event'leri record metadata taşır. Before ve after state bulunabilir. Payload schema version ile ilişkilidir. Sensitive kolonlar korunmalıdır. Consumer target write'ı idempotent yapmalıdır.

Schema History

CDC connector schema değişikliklerini doğru yorumlamak için history tutabilir. Missing history restart sorununa yol açabilir. Storage durable olmalıdır. Migration sırasında uncontrolled DDL engellenmelidir. History backup planına eklenebilir.

Offset

Connector son okuduğu log position'ı offset olarak saklar. Restart sonrası buradan devam eder. Offset kaybı duplicate veya gap yaratabilir. Durable storage kullanılır. Progress migration dashboard'a aktarılabilir.

Replay

Event stream retention yeterliyse consumer geçmiş değişiklikleri yeniden işleyebilir. Target repair veya rebuild mümkün olur. Consumer idempotent olmalıdır. Replay production target'ı aşırı yüklememelidir. Rate limit uygulanabilir.

Migration Framework'leri CI/CD'ye Nasıl Eklenir?

Migration framework'leri schema değişikliklerini versionlu ve tekrar üretilebilir hale getirir. Flyway, Liquibase, Alembic, Django Migrations, Rails Active Record Migrations ve Doctrine Migrations farklı ekosistemlerde bu amacı destekler. Araç seçimi kadar migration policy önemlidir. CI destructive veya blocking değişiklikleri yakalamalıdır. Production deploy sequence expand, application, backfill ve contract aşamalarını desteklemelidir.

Flyway

Flyway versionlu SQL migration yaklaşımı sunar. Migration sırası repository içinde tutulur. CI syntax ve policy kontrolü yapabilir. Long-running data backfill ayrı job olmalıdır. Rollback çoğu zaman forward migration ile planlanmalıdır.

Liquibase

Liquibase changeset tabanlı schema version yönetimi sağlar. Database farklılıklarını belirli ölçüde soyutlayabilir. Change preview review sürecine eklenebilir. Destructive operation approval gerektirebilir. Generated SQL production engine üzerinde incelenmelidir.

Alembic

Alembic Python ve SQLAlchemy ekosisteminde schema migration yönetir. Autogenerate başlangıç sağlar ancak manual review gerekir. Rename işlemi drop/add olarak yanlış algılanabilir. Expand-and-contract ayrı revision'larla uygulanabilir. Backfill ayrı worker olarak tasarlanmalıdır.

Django Migrations

Django schema ve model değişikliklerini migration dosyalarıyla yönetir. Büyük data migration aynı transaction içinde çalıştırılmamalıdır. Schema_editor behavior database'e göre değişebilir. Breaking field değişikliği aşamalı yapılmalıdır. Production data volume test edilmelidir.

Rails Active Record Migrations

Rails migration DSL geliştirme hızını artırır. Her helper production'da online güvenli olmayabilir. Büyük index veya constraint işlemi database-specific option gerektirebilir. Strong migration lint araçları yararlı olabilir. Data backfill background job'a ayrılmalıdır.

Doctrine Migrations

Doctrine PHP ekosisteminde versionlu migration sağlar. Generated SQL mutlaka review edilmelidir. Platform farkları önemlidir. Destructive diff CI'de yakalanabilir. Contract migration ayrı release'e bırakılmalıdır.

Migration CI/CD Sırası Nasıl Olmalı?

Zero downtime migration için deployment sırası kritik öneme sahiptir. Önce migration lint ve expand schema uygulanır. Ardından backward-compatible application version deploy edilir. Health verification sonrasında backfill ve read switch çalıştırılır. Stability window geçmeden contract migration yapılmamalıdır.

Migration Lint

SQL veya framework migration dosyaları policy kurallarından geçirilir. DROP ve unsafe ALTER tespit edilir. Lock riski işaretlenir. Manual approval gerekebilir. CI başarısız migration'ı production'a göndermemelidir.

Expand Migration

Yeni schema öğeleri backward-compatible biçimde eklenir. Existing code çalışmaya devam eder. Index online yöntemle oluşturulur. Constraint enforcement ertelenebilir. Bu aşama hızlı ve geri döndürülebilir olmalıdır.

Application Deployment

Yeni code eski ve yeni schema ile uyumlu deploy edilir. Dual write veya new field population başlatılabilir. Rolling deployment sağlık metriği izlenir. Eski instance'lar tamamen kalkana kadar compatibility korunur. Feature flag başlangıçta kapalı olabilir.

Health Verification

Application error ve latency baseline ile karşılaştırılır. Database lock veya CPU etkisi kontrol edilir. Yeni schema kullanım metriği gözlenir. Problem varsa rollout durdurulur. Backfill başlamadan sistem stabil olmalıdır.

Backfill Job

Historical data batch halinde taşınır. Progress ve error dashboard'da izlenir. Throttle production load'a göre ayarlanır. Job idempotent ve resumable olmalıdır. Completion sonrası validation yapılır.

Read Switch

Application yeni field veya target database üzerinden okumaya başlar. Canary veya flag kullanılabilir. Mismatch ve latency izlenir. Eski read fallback kısa süre tutulabilir. Stability kanıtlanmadan writer veya contract değişmez.

Stability Window

Sistem belirli süre yeni read path ile çalışır. Error, latency ve business metric izlenir. Eski field kullanımının sıfıra indiği görülür. Rollback hâlâ kolaydır. Bu süre risk seviyesine göre günler olabilir.

Contract Migration

Eski kolon veya constraint artık gereksiz olduğunda kaldırılır. Bu destructive aşamadır. Backup alınır. Dependency scan son kez çalıştırılır. Rollback maliyeti artacağı için en sona bırakılır.

Destructive Migration'ları CI/CD'de Nasıl Engelleriz?

CI/CD pipeline migration SQL'ini deploy edilmeden önce analiz ederek riskli değişiklikleri engelleyebilir. DROP COLUMN ve DROP TABLE açık destructive işlemlerdir. Column rename veya NOT NULL eklemek de rolling deployment açısından breaking olabilir. Table rewrite ihtimali ayrıca işaretlenmelidir. Riskli değişiklikler manual approval ve runbook gerektirmelidir.

DROP COLUMN Detection

Pipeline SQL içinde DROP COLUMN arayabilir. Change otomatik fail edilebilir. Usage metric ve compatibility review istenir. Expand-and-contract reference verilebilir. Approval olmadan production çalıştırılmaz.

DROP TABLE Detection

DROP TABLE yüksek riskli operation'dır. Backup ve dependency doğrulaması gerekir. Feature usage sıfır olmalıdır. CI manual approval isteyebilir. Production role doğrudan drop yetkisine sahip olmayabilir.

Column Rename Detection

Rename eski application version'ı bozabilir. CI bunu breaking change olarak işaretleyebilir. Yeni kolon + backfill yaklaşımı önerilir. Heterogeneous migration araçları rename'i farklı yorumlayabilir. Manual review zorunlu olabilir.

NOT NULL Detection

Existing null kayıt varsa migration başarısız olabilir. Table validation uzun sürebilir. CI direct NOT NULL eklemeyi riskli olarak işaretleyebilir. Nullable + backfill + validation yaklaşımı kullanılabilir. Exception için proof istenebilir.

Table Rewrite Detection

DDL planı tüm table rewrite gerektiriyorsa production riski yüksektir. Engine-specific analyzer kullanılabilir. Table size ile risk skoru hesaplanabilir. Online alternative değerlendirilir. Büyük rewrite manual change window'a alınabilir.

Manual Approval

Her risk otomatik engellenemeyebilir. Database owner ve application owner birlikte review yapar. Dry-run sonucu eklenir. Rollback planı görülür. Approval audit trail içinde saklanır.

Migration Dry-Run Nedir?

Dry-run production migration'ın mümkün olduğunca gerçekçi ortamda önceden uygulanmasıdır. Production schema clone ve benzer veri hacmi kullanılır. Migration süresi, lock etkisi ve backfill throughput ölçülür. Rollback de aynı provanın parçasıdır. Gerçek cutover runbook bu sonuçlara göre güncellenir.

Production Schema Clone

Target staging production schema ile aynı olmalıdır. Extension ve index farklılığı sonucu bozabilir. Schema version otomatik karşılaştırılır. Sensitive data gerekmez. Structure fidelity önemlidir.

Production'a Yakın Veri Hacmi

Küçük development dataset migration süresini yanlış gösterir. Büyük table davranışı production'a yakın boyutta test edilmelidir. Synthetic data kullanılabilir. Distribution ve skew gerçekçi olmalıdır. Hot key senaryosu eklenebilir.

Migration Süresi

Her adımın başlangıç ve bitiş zamanı kaydedilir. Full load, backfill ve validation ayrı ölçülür. Cutover kritik path belirlenir. Buffer eklenir. Runbook tahminleri bu veriye dayanır.

Lock Ölçümü

DDL sırasında lock acquisition ve wait süresi ölçülür. Concurrent traffic simüle edilir. Blocking query'ler tespit edilir. lock_timeout ayarı test edilir. Riskli operation alternatif yönteme taşınabilir.

Backfill Throughput

Saniyede kaç row güvenli biçimde işlenebildiği ölçülür. CPU ve I/O etkisi kaydedilir. Replica lag simüle edilebilir. Batch size optimize edilir. Production ETA daha doğru çıkar.

Rollback Rehearsal

Dry-run yalnız forward migration ile bitmemelidir. Feature flag geri alınır. Database writer source'a döndürülür. Data divergence senaryosu test edilir. Rollback süresi gerçek olarak ölçülür.

Migration Game Day Nasıl Yapılır?

Migration game day cutover ve failure senaryolarının ekipçe kontrollü biçimde prova edilmesidir. CDC kesilmesi veya target database failure gibi sorunlar kasıtlı oluşturulur. Ekip rollback runbook'unu gerçek rollerle uygular. Incident communication da prova edilir. Bu çalışma migration gününde karar süresini ciddi biçimde azaltır.

Cutover Provası

Source ve target test ortamında gerçek sequence ile değiştirilir. Feature flag ve pool drain kullanılır. Validation çalıştırılır. Time measurement yapılır. Eksik runbook adımları ortaya çıkar.

CDC Kesilmesi

CDC connector bilinçli durdurulur. Lag alarmının çalıştığı doğrulanır. Source log retention izlenir. Consumer recovery sonrası catch-up yapar. Cutover'ın otomatik engellendiği kontrol edilir.

Network Hatası

Source-target bağlantısı geçici kesilir. Retry ve backoff davranışı görülür. Application normal çalışmaya devam etmelidir. Log retention yeterli olmalıdır. Network geri geldiğinde sync devam etmelidir.

Hedef Database Arızası

Target cutover öncesi veya sonrası kapatılır. Read canary source'a dönebilmelidir. Writer target'taysa rollback procedure çalıştırılır. Data consistency kontrol edilir. Incident owner karar süresini ölçer.

Rollback Provası

Rollback trigger kasıtlı tetiklenir. Routing source'a alınır. Reverse CDC state kontrol edilir. Application version gerekiyorsa geri döner. Kullanıcı etkisi ölçülür.

Incident Roles

Incident commander teknik adımları koordine eder. Database owner data state'i takip eder. Application owner routing ve error metric'i izler. Communication owner stakeholder update verir. Tek kişinin tüm işi yapması beklenmemelidir.

Multi-Tenant Database Migration

Multi-tenant sistemde tüm müşterileri aynı anda target database'e taşımak gereksiz risk yaratır. Internal tenant ile başlamak iyi canary sağlar. Ardından küçük tenant batch'leri kademeli olarak geçirilir. Her tenant için validation ve rollback bağımsız uygulanabilir. Büyük tenant'lar ayrı migration planı gerektirebilir.

Tüm Tenant'ları Aynı Anda Taşımamak

Big bang cutover tüm müşteri kitlesini aynı riske maruz bırakır. Tenant-based routing blast radius'u azaltır. Küçük batch deneyim kazandırır. Problem yalnız sınırlı tenant grubunu etkiler. Rollback daha kolay olur.

Internal Tenant

İlk migration internal veya test tenant üzerinde yapılabilir. Gerçek production infrastructure kullanılır. Business flow ekip tarafından doğrudan gözlenir. Mismatch daha hızlı analiz edilir. Sonraki batch için runbook güncellenir.

Canary Tenant

Düşük riskli gerçek tenant seçilir. Trafik pattern'i normal kullanıcıya yakın olmalıdır. Read ve write target'a yönlendirilebilir. Validation tenant scope'unda yapılır. Stability sonrası batch genişletilir.

Tenant Batch

Tenant'lar küçük gruplar halinde taşınır. Batch size target capacity ve risk toleransına göre seçilir. Her batch arasında gözlem süresi bırakılır. Hot tenant ayrı tutulabilir. Automation state yönetimini kolaylaştırır.

Tenant Bazlı Validation

Row count ve business metric tenant ID üzerinden karşılaştırılır. Missing data belirli müşteriye bağlanabilir. Support etkisi daha kolay yönetilir. Validation tamamlanmadan tenant state "migrated" yapılmaz. Dashboard tenant progress göstermelidir.

Tenant Bazlı Rollback

Yalnız sorunlu tenant source'a döndürülebilir. Diğer müşteriler target'ta kalabilir. Tenant directory route değiştirir. Reverse sync tenant scope'unda çalışabilir. Rollback blast radius'u küçülür.

Tenant-by-Tenant Cutover

Tenant-by-tenant cutover her müşterinin migration state'ini ayrı yönetir. Tenant directory canonical route bilgisini tutar. Application her request'te doğru database'i seçer. Batch size ve large tenant stratejisi migration hızını belirler. Bu model SaaS ortamlarında güçlü operational control sağlar.

Tenant Directory

Her tenant'ın source veya target location bilgisi tutulur. State versionlu olmalıdır. Router local cache kullanabilir. Migration sırasında state atomic değişir. Directory high available olmalıdır.

Routing

Request tenant ID üzerinden doğru database'e gönderilir. Read ve write aynı state'i kullanmalıdır. Stale cache split routing yaratabilir. Route trace içine eklenir. Failback hızlı yapılabilir.

Tenant Migration State

Pending, copying, validating, cutover ve completed gibi state'ler kullanılabilir. State machine yanlış adımı engeller. Her transition audit edilir. Retry idempotent olmalıdır. Operator current phase'i kolayca görür.

Batch Size

Aynı anda taşınan tenant sayısı target ve migration tooling kapasitesine göre ayarlanır. Çok büyük batch blast radius'u büyütür. Çok küçük batch toplam süreyi uzatır. Dynamic scheduling kullanılabilir. Hot tenant batch dışında tutulabilir.

Large Tenant'ı Ayrı Taşımak

Büyük müşterinin data ve QPS profili farklıdır. Dedicated migration window planlanabilir. Full load ve validation daha uzun sürebilir. Capacity target üzerinde önceden ayrılır. Support ve business owner ayrıca bilgilendirilebilir.

Sharded Database Migration

Sharded database migration tek database taşımaktan daha fazla orchestration gerektirir. Her shard ayrı migration unit olarak ele alınabilir. Routing layer source ve target shard topology'sini bilmelidir. CDC shard bazında ilerleme ve lag göstermelidir. Cross-shard validation global business state'in doğru kalmasını sağlar.

Shard Bazlı Migration

Shard'lar küçük gruplar halinde taşınabilir. Low-traffic shard canary olarak seçilebilir. Her shard için full load ve CDC ayrı takip edilir. Failure yalnız sınırlı kullanıcı grubunu etkiler. Automation shard state'ini yönetir.

Shard Routing

Router hangi shard'ın source veya target cluster'da olduğunu bilir. Mapping versionlu olmalıdır. Cutover atomic state change ile yapılır. Stale router cache risklidir. Redirect veya refresh mekanizması bulunmalıdır.

Shard CDC

Her shard kendi transaction log stream'ine sahip olabilir. Lag per-shard izlenir. Hot shard daha fazla backlog üretebilir. Target shard capacity ayrı boyutlandırılır. Cutover yalnız ilgili shard lag düşükken yapılır.

Hot Shard

Yüksek write alan shard migration'ı daha uzun sürebilir. CDC catch-up zorlaşabilir. Full load throttle farklı ayarlanır. Dedicated target capacity gerekebilir. Hot shard en sona bırakılabilir.

Kademeli Cutover

Shard'lar sırayla target topology'ye alınır. Global application iki ortamla bir süre çalışır. Routing abstraction bu nedenle önemlidir. Her shard sonrası stability gate uygulanır. Tüm cluster aynı anda risk altında olmaz.

Cross-Shard Validation

Global aggregate birden fazla shard'ın birlikte doğru state taşımasını gerektirir. Per-shard checksum tek başına yeterli olmayabilir. Cross-shard relation veya totals kontrol edilir. Analytics query ayrı doğrulama sistemi kullanabilir. Final migration closure global validation ister.

Region-to-Region Database Migration

Region-to-region migration network latency ve cross-region transfer maliyetini beraberinde getirir. Replication source ve target region arasında sürekli çalışır. Data residency hangi kayıtların taşınabileceğini sınırlayabilir. Cutover user routing ile database routing'i birlikte değiştirebilir. Disaster recovery ile migration aynı teknikleri kullansa da hedefleri farklıdır.

Network Latency

Cross-region round-trip CDC ve synchronous operation süresini etkiler. Full load throughput bandwidth ile sınırlanabilir. Compression yardımcı olabilir. Packet loss migration hızını düşürür. Network benchmark önceden yapılmalıdır.

Replication

Cross-region async replication genellikle düşük source impact sağlar. Lag network mesafesine bağlıdır. Target apply kapasitesi yine önemlidir. Failover ve migration replication amaçları ayrılmalıdır. Cutover öncesi position doğrulanır.

Data Residency

Regülasyon belirli verinin başka region'a taşınmasını yasaklayabilir. Migration scope buna göre filtrelenir. Temporary staging copy de aynı kurallara tabidir. Backup location ayrıca kontrol edilir. Compliance owner planı onaylamalıdır.

Cross-Region Egress

Büyük database migration ciddi network egress maliyeti yaratabilir. Full load byte miktarı hesaplanmalıdır. Retry ve duplicate transfer ekstra maliyet getirir. Compression azaltabilir. Cost migration planında görünür olmalıdır.

Regional Cutover

User traffic yeni region'a kademeli alınabilir. Database writer ve application region uyumu gerekir. Cache ve message queue bağımlılıkları ayrıca taşınabilir. DNS veya global load balancer route değiştirir. Latency business metric ile doğrulanır.

Disaster Recovery ile Migration Arasındaki Fark

DR failure sonrası hızlı recovery hedefler. Migration planlı ve kontrollü topology değişikliğidir. DR replica her zaman production target readiness taşımayabilir. Migration validation daha kapsamlıdır. Aynı replication teknolojisi farklı operasyon amacıyla kullanılabilir.

Database Encryption ve Migration

Migration sırasında veri source ile target arasında hareket ettiği için encryption politikası yeniden değerlendirilmelidir. In-transit encryption network üzerindeki veriyi korur. At-rest encryption target disk ve backup üzerinde sürdürülmelidir. KMS veya customer-managed key yaklaşımı compliance ihtiyacına göre seçilebilir. Credential ve key rotation cutover planının parçası olmalıdır.

Encryption in Transit

Database bağlantıları TLS ile korunmalıdır. Migration worker source ve target sertifikalarını doğrulamalıdır. Plaintext internal network varsayımı yapılmamalıdır. Certificate rotation planı migration süresini kapsamalıdır. Performance overhead benchmark edilebilir.

Encryption at Rest

Target storage encryption aktif olmalıdır. Snapshot ve backup aynı politikayı izlemelidir. Encryption setting sonradan değiştirmek zor olabilir. Hedef provisioning aşamasında doğrulanmalıdır. Key access restore sürecinde test edilmelidir.

KMS

Key Management Service encryption key lifecycle'ını merkezi yönetebilir. Migration service gerekli key permission'a sahip olmalıdır. Least privilege uygulanır. Key outage target database erişimini etkileyebilir. Audit log etkin tutulmalıdır.

CMEK/BYOK

Customer-managed veya bring-your-own-key modeli daha fazla kontrol sağlar. Key ownership organization'da kalır. Rotation ve revocation procedure önemlidir. Migration target'ın bu modeli desteklediği doğrulanmalıdır. Key kaybı ciddi recovery problemi yaratabilir.

Key Rotation

Migration sırasında aynı anda büyük key rotation yapmak gereksiz risk olabilir. Ayrı change olarak planlanması daha güvenlidir. Zorunluysa source ve target access test edilir. Re-encryption load izlenir. Rollback key state ile uyumlu olmalıdır.

Hedef Database Credential'ları

Target credential önceden secret manager içinde oluşturulur. Application cutover role'ü minimum permission taşımalıdır. Migration user ile runtime user ayrı tutulur. Credential loglara yazılmamalıdır. Source credential decommission sonrası iptal edilir.

Migration Güvenliği

Migration araçları geniş veri erişimi gerektirebildiği için güvenlik tasarımı özel önem taşır. Migration user yalnız gerekli read veya CDC yetkilerini almalıdır. Target write permission ayrı role verilebilir. Secret manager temporary credential kullanımını kolaylaştırır. Tüm kritik işlemler audit log içinde izlenmelidir.

Least Privilege Migration User

Migration service root veya superuser credential kullanmamalıdır. Yalnız gerekli schema ve table erişimi verilmelidir. DDL gerekiyorsa ayrı role kullanılabilir. Permission migration sonunda kaldırılır. Access review yapılmalıdır.

Kaynak Read Permissions

Full load için gerekli tablolar okunabilmelidir. Hassas veya scope dışı tablo erişimi verilmemelidir. Row-level restriction gerekiyorsa uygulanır. Snapshot permission ayrıca gerekebilir. Audit source read activity'yi kaydeder.

CDC Permissions

Transaction log okuma için özel replication permission gerekebilir. PostgreSQL slot veya MySQL binlog erişimi minimum kapsamda açılır. Credential yalnız migration service tarafından kullanılmalıdır. Retention object'leri kontrollü oluşturulur. Migration sonrası permission kaldırılır.

Target Write Permissions

Migration worker target'a insert, update ve delete yapabilir. DDL yetkisi yalnız gerekiyorsa verilmelidir. Runtime application role ayrı tutulur. Accidental destructive command sınırlandırılır. Permission set test ortamında doğrulanır.

Secret Manager

Database password config dosyasında saklanmamalıdır. Secret manager runtime erişimi sağlar. Rotation merkezi yapılabilir. Audit hangi service'in secret okuduğunu gösterir. CI loglarına secret sızmamalıdır.

Temporary Credentials

Migration-specific credential kısa ömürlü olabilir. Cutover tamamlandıktan sonra expire edilir. Long-lived shared password riski azalır. Automation token renewal davranışını desteklemelidir. Emergency access ayrı tutulur.

Audit Logging

Migration user'ın tüm kritik erişimleri kaydedilmelidir. DDL ve permission değişiklikleri ayrıca izlenir. Audit log immutable storage'a gönderilebilir. Sensitive query parameter maskeleme uygulanır. Incident sonrası timeline çıkarmaya yardımcı olur.

KVKK ve Database Migration

Kişisel veri içeren migration süreçlerinde KVKK yükümlülükleri teknik taşıma planının parçası olarak ele alınmalıdır. Temporary copy ve staging ortamı da kişisel veri işleme kapsamına girebilir. Encryption ve retention politikası source kadar target için de uygulanmalıdır. Backup kopyaları migration tamamlandıktan sonra gereksiz süre tutulmamalıdır. Kaynak database'in güvenli silinmesi de decommission aşamasının bir parçasıdır.

Kişisel Veri

Hangi tabloların kişisel veri içerdiği sınıflandırılmalıdır. Migration scope yalnız gerekli alanları kapsamalıdır. Hassas veri loglanmamalıdır. Access minimum yetkiyle sınırlandırılır. Data owner migration planına dahil edilmelidir.

Temporary Copies

Migration sırasında intermediate snapshot veya export oluşabilir. Bu kopyalar production data ile aynı güvenlik seviyesinde korunmalıdır. Temporary bucket public olmamalıdır. Retention kısa tutulmalıdır. İş bittikten sonra güvenli silinmelidir.

Staging Data

Production data staging'e doğrudan taşınmamalıdır. Masking veya anonymization tercih edilmelidir. Gerçekçi volume synthetic data ile oluşturulabilir. Zorunlu gerçek data için erişim sınırlandırılır. Environment isolation uygulanmalıdır.

Backup

Migration backup'ları encryption ve retention policy'ye tabi olmalıdır. Cross-region storage compliance açısından değerlendirilir. Restore access yalnız yetkili ekipte bulunur. Backup lifecycle otomatik silme kullanabilir. Audit kayıtları tutulmalıdır.

Encryption

In-transit ve at-rest encryption kişisel veri için temel korumadır. Key access sınırlandırılmalıdır. Target encryption source seviyesinden düşük olmamalıdır. Temporary file'lar da şifrelenmelidir. Key management audit edilmelidir.

Retention

Migration artifact'ları gereksiz süre saklanmamalıdır. Source retention business ve yasal ihtiyaca göre belirlenir. DLQ veya error log hassas payload içerebilir. Otomatik cleanup uygulanır. Retention policy dokümante edilmelidir.

Kaynak Database'in Güvenli Silinmesi

Decommission yalnız instance shutdown değildir. Snapshot ve temporary replica'lar da değerlendirilmelidir. Credential iptal edilir. Storage lifecycle tamamlanır. Silme işlemi audit evidence üretmelidir.

Migration Performansı Nasıl Optimize Edilir?

Migration performance hedefi data'yı mümkün olan en hızlı şekilde taşımak olmamalıdır. Parallel load ve uygun batch size süreyi azaltabilir. Compression network darboğazını hafifletebilir. Target index stratejisi write throughput'u etkiler. Source production load ve replication instance capacity her optimizasyon kararında sınır olarak kullanılmalıdır.

Parallel Load

Birden fazla table veya chunk eş zamanlı taşınabilir. Throughput artar. Aşırı parallelism source ve target database'i doygunlaştırabilir. Worker sayısı dynamic ayarlanabilir. Hot table ayrı limit kullanabilir.

Batch Size

Büyük batch network verimliliğini artırabilir. Transaction süresi ve memory kullanımı da artar. Optimal değer workload'a göre test edilir. Error recovery küçük batch'te daha ucuzdur. Batch size metric-driven olabilir.

Compression

Network bandwidth darboğazsa compression faydalı olabilir. CPU maliyeti eklenir. Source ve migration worker kapasitesi ölçülmelidir. Already compressed blob data çok az kazanç sağlar. Algorithm latency ve ratio açısından test edilir.

Network Throughput

Full load hızı network kapasitesinden yüksek olamaz. Cross-region link benchmark edilmelidir. Packet loss ve VPN overhead ölçülür. Dedicated bağlantı gerekebilir. Egress maliyeti ayrıca hesaplanır.

Target Indexes

Her insert çok sayıda index güncelliyorsa full load yavaşlar. Bazı noncritical index'ler load sonrası oluşturulabilir. Ancak CDC ve query validation ihtiyacı düşünülmelidir. Unique index data integrity için gerekli olabilir. Plan engine behavior'a göre hazırlanır.

Source Load

Migration production user workload'undan kaynak çalmamalıdır. Read replica full load source'u olarak kullanılabilir. Throttle source CPU ve I/O'ya bağlanır. Peak saatlerde hız düşürülür. User SLO her zaman önceliklidir.

Replication Instance Sizing

Managed migration worker CPU, memory ve network açısından doğru boyutlandırılmalıdır. Yetersiz instance CDC lag üretir. Çok büyük instance target database'i aşırı yükleyebilir. Benchmark gerçek workload ile yapılır. Migration boyunca autoscaling davranışı izlenebilir.

Migration Hızından Daha Önemli Olan Nedir?

Migration'ın birkaç saat erken bitmesi data kaybından veya kullanıcı outage'ından daha değerli değildir. Veri tutarlılığı en temel başarı kriteridir. Application availability migration boyunca korunmalıdır. Rollback seçeneği riskli adımlarda açık tutulmalıdır. Reproducibility ve observability ekiplerin migration'ı güvenle tekrar etmesini sağlar.

Veri Tutarlılığı

Source ve target aynı business state'i taşımalıdır. Missing row kabul edilmemelidir. Transaction ordering korunmalıdır. Validation sürekli çalışmalıdır. Hız uğruna correctness feda edilmemelidir.

Uygulama Kullanılabilirliği

Database migration kullanıcıya outage olarak yansımamalıdır. Error ve latency SLO izlenir. Background migration gerektiğinde throttle edilir. Feature flag blast radius'u azaltır. Application metric teknik progress'ten önceliklidir.

Rollback

Her kritik aşamanın geri dönüş yolu olmalıdır. Writer switch sonrası rollback daha zorlaşır. Reverse sync gerekebilir. Rollback test edilmeden migration güvenli değildir. Point of no return geciktirilmelidir.

Reproducibility

Migration manual komut dizisi olarak kalmamalıdır. Script ve runbook version control'de tutulur. Aynı işlem staging'de tekrar çalıştırılabilir. State machine recovery sağlar. İnsan hatası azalır.

Observability

Progress, lag ve mismatch görünür olmalıdır. Operator tahmin yürütmek zorunda kalmamalıdır. Trace database route bilgisini taşıyabilir. Alert critical threshold'u otomatik bildirir. Migration sonrası veriler postmortem için saklanabilir.

Zero-Downtime Migration'da Sık Yapılan Hatalar

Zero downtime migration hataları çoğu zaman büyük tek SQL, zayıf gözlem veya plansız cutover yaklaşımından kaynaklanır. Hot table üzerinde doğrudan ALTER TABLE çalıştırmak ilk örnektir. Schema ve application deploy'unu tek adıma bağlamak rollback alanını daraltır. CDC lag ve validation görmezden gelindiğinde data divergence ortaya çıkabilir. Eski database'i çok erken kapatmak son güvenlik ağını ortadan kaldırır.

ALTER TABLE'ı Doğrudan Hot Table'da Çalıştırmak

DDL lock kullanıcı write'larını bloke edebilir. Table size büyüdükçe risk artar. Online alternatifler değerlendirilmelidir. Dry-run lock süresini ölçer. Timeout safety guard eklenmelidir.

Schema ve Application Deploy'u Tek Adım Yapmak

Breaking schema change eski application instance'larını bozabilir. Rollback imkansız hale gelebilir. Expand-and-contract deploy'ları ayırır. Compatibility window korunur. Contract en sona bırakılır.

Büyük Backfill'i Tek Transaction'da Yapmak

Uzun transaction lock ve log üretimini artırır. Failure tüm işlemi tekrar gerektirebilir. Replica lag büyür. Batch processing daha güvenlidir. Checkpoint recovery kolaylaştırır.

CDC Lag'i İzlememek

Target saatlerce geride kalabilir. Cutover data loss veya stale state yaratabilir. Lag dashboard'da görünmelidir. Threshold quality gate olmalıdır. Apply capacity düzenli kontrol edilir.

Dual Write Hatalarını Görmezden Gelmek

Target write failure sessizce atlanmamalıdır. Reconciliation queue gereklidir. Idempotency duplicate retry'ı güvenli yapar. DLQ izlenmelidir. Source of truth açık kalmalıdır.

Validation Yapmadan Cutover

Data copy completion correctness garantisi değildir. Row count ve checksum yapılmalıdır. Shadow read real query behavior'u test eder. Business total ayrıca doğrulanır. Validation gate geçmeden writer değişmemelidir.

DNS TTL'yi Unutmak

Eski DNS record client cache'inde kalabilir. Cutover sonrası bazı instance source'a bağlanmaya devam eder. TTL önceden düşürülmelidir. Existing connection ayrıca drain edilmelidir. DNS tek control mekanizması olmamalıdır.

Connection Pool'ları Unutmak

Pool eski socket'leri uzun süre tutabilir. New endpoint config tek başına yeterli değildir. Maximum lifetime ayarlanmalıdır. Drain ve reconnect uygulanır. Connection storm önlenmelidir.

Rollback Provası Yapmamak

Kağıt üzerindeki rollback gerçek incident'ta çalışmayabilir. Credential veya route unutulabilir. Reverse CDC state yanlış olabilir. Game day ile prova yapılmalıdır. Süre gerçek olarak ölçülmelidir.

Eski Database'i Çok Erken Kapatmak

Final mismatch sonradan ortaya çıkabilir. Source debugging ve rollback için değerlidir. Read-only grace period tutulmalıdır. Audit source kullanımını izler. Decommission ayrı aşamada yapılmalıdır.

Production Öncesi Zero-Downtime Migration Kontrol Listesi

Production migration başlamadan önce teknik ve operasyonel hazırlıkların tamamı kontrol edilmelidir. Success criteria ve rollback trigger açık olmalıdır. Backup restore testi ve source-target schema doğrulaması tamamlanmalıdır. CDC, backfill ve validation pipeline'ı gerçek veri hacmine yakın ortamda denenmelidir. Monitoring dashboard ve decommission planı migration öncesinde hazır bulunmalıdır.

Success Criteria Belirlendi mi?

Downtime, lag ve error threshold sayısal olmalıdır. Business metric hedefi eklenmelidir. Cutover owner kriterleri bilmelidir. Criteria runbook'ta görünür olmalıdır. Değişiklik migration günü yapılmamalıdır.

Backup ve Restore Test Edildi mi?

Backup başarı logu tek başına yeterli değildir. Restore gerçek test ortamında yapılmalıdır. Süre RTO ile karşılaştırılır. Encryption key erişimi kontrol edilir. Data doğruluğu restore sonrası test edilir.

Source/Target Schema Doğrulandı mı?

Table, index ve constraint karşılaştırılır. Data type mapping test edilir. Extension ve function farkı raporlanır. Schema drift otomatik tespit edilebilir. Cutover öncesi target beklenen version'da olmalıdır.

Long-Running Transaction'lar Kontrol Edildi mi?

Cutover öncesi açık uzun transaction listelenir. DDL lock riskleri görülür. Gerekirse işlem sahipleriyle koordinasyon yapılır. Query timeout politikası uygulanır. Unexpected transaction go/no-go kararını etkileyebilir.

DDL Lock Davranışı Test Edildi mi?

Production'a yakın load altında migration DDL çalıştırılır. Lock level kaydedilir. statement_timeout ve lock_timeout test edilir. Blocking query impact ölçülür. Unsafe operation alternative yönteme çevrilir.

CDC Çalışıyor mu?

Source change target'ta doğru sırada görünmelidir. Connector restart test edilir. Offset veya LSN persistence doğrulanır. DDL behavior bilinmelidir. Monitoring alarm üretmelidir.

Replication Lag Kabul Edilebilir mi?

Normal ve peak workload altında lag ölçülür. Target catch-up yapabilmelidir. Cutover threshold belirlenir. Backfill lag'i yükseltiyorsa throttle uygulanır. Trend istikrarlı olmalıdır.

Backfill Idempotent mı?

Aynı batch iki kez çalıştırılır. Data sonucu değişmemelidir. Checkpoint restart test edilir. Partial failure simüle edilir. Retry permanent error'ı saklamamalıdır.

Data Validation Geçiyor mu?

Row count ve checksum eşleşmelidir. Business metric karşılaştırılır. Shadow read mismatch kabul edilen sınırda olmalıdır. Referential integrity kontrol edilir. Failure cutover'ı durdurmalıdır.

Feature Flag Hazır mı?

Read ve write route ayrı kontrol edilebilir olmalıdır. Flag permission sınırlandırılır. Change audit edilir. Stale config test edilir. Emergency rollback procedure bilinir.

Connection Pool Cutover Planı Var mı?

Pool drain sequence belirlenir. Maximum lifetime önceden ayarlanır. New connection rate limit edilir. Target max connection headroom doğrulanır. Prepared statement cache davranışı test edilir.

Rollback Test Edildi mi?

Game day sırasında gerçek rollback çalıştırılır. Writer source'a döndürülür. Data sync state kontrol edilir. Uygulama version gerekirse geri alınır. Süre RTO hedefiyle karşılaştırılır.

Monitoring Dashboard Hazır mı?

Lag, error ve latency tek ekranda olmalıdır. Source ve target metric'leri yan yana gösterilir. Traffic percentage görünürdür. Alert routing doğru owner'a gider. Dashboard migration başlamadan kullanıma hazırdır.

Decommission Planı Hazır mı?

Source ne zaman read-only ve ne zaman kapalı olacak belirlenir. Final reconciliation adımı yazılır. Backup retention tanımlanır. Credential revocation planlanır. Data deletion compliance ile uyumlu olmalıdır.

Uçtan Uca Örnek: PostgreSQL Schema Migration

Pratik bir PostgreSQL migration örneğinde mevcut kolonu breaking biçimde değiştirmek yerine expand-and-contract kullanılabilir. Önce yeni kolon eklenir ve gerekliyse concurrent index oluşturulur. Application dual write yapmaya başlar. Historical data batched backfill ile taşınır ve doğrulanır. Stability window sonrasında eski kolon contract aşamasında kaldırılır.

Yeni Kolonu Eklemek

Yeni kolon nullable olarak eklenir. Eski code etkilenmez. DDL lock süresi test edilmiştir. Application henüz yeni alana bağımlı değildir. Expand aşaması tamamlanır.

Concurrent Index Oluşturmak

Yeni access pattern için CREATE INDEX CONCURRENTLY kullanılabilir. CPU ve I/O izlenir. Failure sonrası index validity kontrol edilir. Query plan test edilir. Index production trafiğini engellememelidir.

Dual Write Kodunu Deploy Etmek

Yeni application aynı değeri eski ve yeni kolona yazar. Rolling deployment boyunca eski instance'lar çalışabilir. Mismatch metric eklenir. Hata durumunda transaction davranışı test edilir. Eski kolon hâlâ source of truth olabilir.

Batched Backfill

Historical row'lar primary key range ile işlenir. Batch size düşük tutulur. Job checkpoint taşır. Replica lag yükselirse throttle edilir. Completion dashboard'da izlenir.

Veri Doğrulaması

Eski ve yeni kolon değerleri karşılaştırılır. Null count kontrol edilir. Sample ve aggregate validation yapılır. Mismatch sıfıra indirilir. Read switch bundan sonra başlar.

Read Path'i Değiştirmek

Feature flag yeni kolonu read source yapar. Canary traffic ile başlanır. Error ve latency izlenir. Eski kolon fallback olabilir. Yüzde yüz rollout sonrası stability süresi başlar.

Stability Window

Sistem birkaç deployment döngüsü yeni kolonla çalışır. Eski field read ve write metric'i sıfıra iner. Rollback hâlâ mümkündür. Backup alınır. Dependency scan tekrarlanır.

Eski Kolonu Contract Aşamasında Silmek

Eski kolon artık kullanılmadığında DROP planlanır. DDL lock behavior tekrar kontrol edilir. Change ayrı release olur. Rollback maliyeti artar. Migration ancak sonrasında tamamen kapanır.

Uçtan Uca Örnek: On-Prem PostgreSQL'i Cloud'a Taşımak

On-prem PostgreSQL migration'ında ilk iş source workload ve network kapasitesini ölçmektir. Cloud target production'a uygun kapasitede hazırlanır. Initial load historical data'yı taşırken CDC yeni değişiklikleri aktarır. Shadow read ve feature flag target behavior'unu production trafiğiyle doğrular. Writer switch sonrasında final reconciliation yapılır ve source ancak grace period sonunda kapatılır.

Source Assessment

Database size, table listesi ve throughput ölçülür. Extension ve stored procedure envanteri çıkarılır. Long transaction analizi yapılır. Backup restore testi tamamlanır. Migration duration tahmini hazırlanır.

Hedef Database Provisioning

Cloud database CPU, memory ve storage açısından boyutlandırılır. Encryption aktif edilir. Network ve private access hazırlanır. User ve permission oluşturulur. Query benchmark hedefte çalıştırılır.

Network

On-prem ile cloud arasında güvenli bağlantı kurulur. Throughput ölçülür. Latency ve packet loss test edilir. Firewall rule minimum tutulur. Full load ETA network sonucuna göre güncellenir.

Initial Load

Historical data target'a taşınır. Büyük tablolar parallel olabilir. Source load izlenir. Data copy checkpoint taşır. Row progress dashboard'da görünür.

CDC

Logical replication veya migration service yeni değişiklikleri takip eder. WAL retention yeterli olmalıdır. Target apply rate ölçülür. Lag alarmı kurulur. Cutover'a kadar source writer kalır.

Continuous Validation

Source ve target sürekli karşılaştırılır. Row count ve checksum schedule edilir. Business aggregate farkı izlenir. Mismatch repair edilir. Cutover öncesi uzun süre stabil sonuç aranır.

Shadow Reads

Production query örnekleri cloud target'a gönderilir. User response source'tan dönmeye devam eder. Result ve latency karşılaştırılır. Target index eksikleri ortaya çıkar. Traffic sampling kontrollü artırılır.

Feature-Flag Cutover

Read traffic önce küçük cohort ile target'a alınır. Quality gate geçtikçe oran artırılır. Writer hâlâ on-prem source olabilir. Connection pool target behavior'u test edilir. Rollback flag ile hızlı yapılabilir.

Writer Switch

CDC lag düşük seviyeye getirilir. Source write fenced edilir. Target writer açılır. Application connection pool yeni endpoint'e geçer. İlk transaction'lar doğrulanır.

Final Reconciliation

Cutover sonrası row ve business total tekrar karşılaştırılır. Missing transaction aranır. Sequence state kontrol edilir. Source read-only tutulur. Stability sonucu decommission kararı verilir.

Source Decommission

Grace period sonunda source connection kullanımı kontrol edilir. Final backup alınır. Credential iptal edilir. On-prem storage güvenli biçimde kapatılır. Audit evidence saklanır.

Veritabanı Migration İçin En İyi Programlama Dili Hangisidir?

Database migration için tek bir en iyi programlama dili yoktur. SQL schema ve data manipulation temelidir. Python automation ve validation tooling için güçlüdür. Go, Java ve TypeScript farklı service ve migration orchestration ihtiyaçlarında kullanılabilir. Dil seçiminden daha önemli olan transaction, locking, replication ve distributed systems davranışını doğru anlamaktır.

SQL

Migration'ın temel dili çoğu zaman SQL'dir. Schema ve query behavior doğrudan burada görülür. DDL lock etkisi bilinmelidir. Set-based data operation verimlidir. SQL bilmeden migration riskini değerlendirmek zordur.

Python

Python validation ve automation script'leri için hızlı geliştirme sağlar. Database driver ekosistemi geniştir. Chunked backfill kolay yazılabilir. Memory'ye tüm dataset alınmamalıdır. Retry ve checkpoint production kalitesinde tasarlanmalıdır.

Go

Go yüksek concurrency migration worker veya proxy geliştirmek için kullanılabilir. Static binary deployment kolaylık sağlar. Context timeout ve cancellation kullanışlıdır. Worker backpressure uygulamalıdır. Database correctness yine dil dışı konudur.

Java

Java enterprise migration orchestration ve ETL sistemlerinde güçlü ekosisteme sahiptir. Connection pool ve transaction tooling olgundur. Large batch processing dikkatle ayarlanmalıdır. JVM memory behavior izlenmelidir. Existing enterprise platform seçimi etkiler.

TypeScript

TypeScript application-level dual write ve validation servislerinde kullanılabilir. Type safety schema dönüşümünde faydalıdır. Node.js connection ve concurrency davranışı iyi yönetilmelidir. Long-running batch process backpressure kullanmalıdır. Migration code production service standardında olmalıdır.

Bash

Bash küçük orchestration ve operational komutlarda yararlıdır. Complex state machine için uygun değildir. Error handling açık yapılmalıdır. `set -e` tek başına yeterli güvence değildir. Critical migration logic daha test edilebilir araçta tutulmalıdır.

Programlama Dilinden Daha Önemli Olan Database ve Distributed Systems Bilgisi

Lock, transaction ve replication davranışı kullandığınız dilden bağımsızdır. Network timeout ve partial failure her teknolojide ortaya çıkar. Idempotency migration recovery'nin temelidir. Data validation tooling'den daha önemlidir. Güçlü database temeli araç değişse bile geçerliliğini korur.

Yazılımcı Olmak İçin Ne Yapmalı? Database Engineering Yol Haritası

Database engineering alanında ilerlemek isteyen geliştirici SQL ve transaction temellerinden başlamalıdır. Indexing ve locking gerçek performance problemlerini anlamayı sağlar. PostgreSQL veya MySQL üzerinde replication ve CDC laboratuvarları kurulabilir. Docker ve CI/CD bu deneyleri tekrar üretilebilir hale getirir. En güçlü portföy çalışması gerçek bir zero downtime migration projesini baştan sona uygulamaktır.

SQL

SELECT yazmanın ötesinde execution plan öğrenilmelidir. Join ve aggregation maliyeti anlaşılmalıdır. DDL ve transaction behavior incelenmelidir. Büyük dataset üzerinde pratik yapılmalıdır. SQL database engineering'in temel aracıdır.

Transaction

Commit ve rollback davranışı öğrenilmelidir. Long transaction'ın lock ve replication etkisi görülmelidir. Transaction boundary business operation'a göre seçilir. Distributed transaction farkı anlaşılır. Migration sırasında atomicity önemlidir.

Isolation Levels

Read committed, repeatable read ve serializable gibi seviyeler incelenmelidir. Anomaly örnekleri laboratuvarda oluşturulabilir. Snapshot migration behavior'u etkileyebilir. Engine default'ları farklı olabilir. Application expectation açık olmalıdır.

Indexing

B-tree ve composite index mantığı öğrenilmelidir. Index write maliyeti anlaşılmalıdır. Online index build test edilmelidir. EXPLAIN plan okunmalıdır. Migration target index strategy tasarlanabilir.

Locking

Row ve table lock farkı öğrenilmelidir. Blocking chain gözlemlenmelidir. Deadlock oluşturulup analiz edilebilir. DDL lock seviyeleri ayrıca çalışılmalıdır. lock_timeout kullanımı test edilmelidir.

PostgreSQL veya MySQL

En az bir relational engine derin öğrenilmelidir. Backup, restore ve replication lab kurulmalıdır. Configuration default'ları incelenmelidir. Major version behavior takip edilmelidir. İkinci engine daha sonra karşılaştırmalı öğrenilebilir.

Replication

Primary-replica ortamı kurulabilir. Lag yapay olarak artırılır. Failover yapılır. Sync ve async davranışı karşılaştırılır. Monitoring metric'leri toplanır.

CDC

Transaction log'dan event çıkarmak pratik edilmelidir. Debezium veya native logical replication kullanılabilir. Offset ve replay test edilir. Consumer idempotent yapılır. Log retention problemi simüle edilir.

Docker

Birden fazla database node local ortamda kolayca kurulabilir. Network failure simüle edilir. Version matrix test edilebilir. Migration lab tekrar üretilebilir olur. Production behavior birebir aynı kabul edilmemelidir.

CI/CD

Migration lint pipeline'a eklenebilir. Expand ve contract farklı stage olabilir. Backfill job deployment'tan ayrılır. Manual approval policy yazılır. Rollback rehearsal automation ile desteklenir.

Observability

Lag, error ve latency metric toplanmalıdır. Dashboard gerçek migration progress göstermelidir. Trace source veya target route bilgisini içerebilir. Alert quality gate'lere bağlanabilir. Ölçüm olmadan migration güvenli değildir.

Gerçek Bir Zero-Downtime Migration Projesi Yapmak

İki database arasında full load ve CDC kurulabilir. Shadow read eklenir. Feature flag ile canary cutover uygulanır. Deliberate failure sonrası rollback yapılır. Bu çalışma teoriyi production düşüncesine dönüştürür.

Open Source ve İşbirliği ile Migration Yetkinliği Geliştirmek

Database migration becerisi yalnız doküman okuyarak değil, gerçek araçların kodunu ve issue geçmişini inceleyerek de gelişir. PostgreSQL, MySQL, Debezium, gh-ost ve pg_repack farklı migration problemlerini gösterir. Flyway ve Liquibase schema automation yaklaşımını öğretir. GitHub issue ve pull request süreçleri edge case düşüncesini güçlendirir. Migration runbook paylaşımı ekiplerin ortak operasyon standardı oluşturmasına yardım eder.

PostgreSQL

PostgreSQL documentation lock ve replication davranışını anlamak için güçlü kaynaktır. Source code ve mailing list discussion edge case gösterir. Logical replication lab kurulabilir. Major version release note takip edilmelidir. Küçük documentation katkısı iyi başlangıçtır.

MySQL

Online DDL ve replication behavior açık kaynak ekosisteminde incelenebilir. Binlog testleri yapılabilir. Version farkları karşılaştırılabilir. Bug report okumak production edge case'leri gösterir. Upgrade ve migration birlikte çalışılabilir.

Debezium

Connector offset ve schema history davranışı öğrenilebilir. Local Kafka lab kurulabilir. Connector restart ve replay test edilir. Issue tracker gerçek CDC problemlerini gösterir. Küçük test contribution faydalıdır.

gh-ost

Ghost table ve binlog yaklaşımı uygulamalı incelenebilir. Lab ortamında online ALTER yapılabilir. Throttling behavior test edilir. Cutover failure simüle edilir. Tool source code production trade-off'larını gösterir.

pg_repack

Table rewrite ve bloat problemleri üzerinde pratik yapılabilir. Disk ihtiyacı ölçülür. Lock behavior gözlenir. Version compatibility incelenir. Maintenance operation ile migration arasındaki ilişki anlaşılır.

Flyway ve Liquibase

Schema versioning ve CI integration pratiği sağlar. Destructive migration policy geliştirilebilir. Multi-environment rollout test edilir. Drift detection eklenebilir. Tooling ekip standardına dönüştürülebilir.

GitHub Issue

Gerçek bug reproduction teknik öğrenmeyi hızlandırır. Environment ve version bilgisi doğru yazılmalıdır. Minimal example hazırlanır. Root cause discussion takip edilir. Bu çalışma production debugging becerisini geliştirir.

Pull Request

Küçük test veya documentation değişikliğiyle başlanabilir. Review feedback code quality'yi geliştirir. Migration edge case'lerine katkı yapılabilir. Benchmark sonucu açık paylaşılmalıdır. Düzenli contribution teknik portföy oluşturur.

Migration Runbook Paylaşımı

Runbook ekip içinde ortak bilgi oluşturur. Başarısız migration'dan öğrenilenler eklenir. Checklist zamanla olgunlaşır. Game day sonuçları dokümana yansır. Yeni ekip üyesi aynı standardı takip eder.

Diyarbakır Yazılım Topluluğu ile Database Migration Çalışmaları

Diyarbakır Yazılım Topluluğu içinde database migration konularını uygulamalı laboratuvarlarla çalışmak, teori ile production davranışı arasındaki farkı görmek için güçlü bir yöntemdir. PostgreSQL ve MySQL workshoplarıyla başlayan süreç CDC, backfill ve rollback egzersizleriyle derinleştirilebilir. Topluluk projelerini https://www.diyarbakiryazilim.com.tr/projects üzerinden inceleyebilirsiniz. Topluluk ve çalışma yaklaşımı hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Veritabanı migration ve DBA danışmanlığı yakınımda şeklinde yerel bir öğrenme veya işbirliği arayışında olan geliştiriciler için uygulamalı proje üretmek, yalnız sunum dinlemekten çok daha kalıcı deneyim sağlar.

Diyarbakır Yazılım Topluluğu İçinde Database Engineering

Database engineering çalışmaları küçük production benzeri lab ortamlarında yürütülebilir. Katılımcılar primary-replica ve CDC kurabilir. Failure scenario bilinçli olarak oluşturulabilir. Metric ve dashboard birlikte geliştirilir. Sonuçlar ortak teknik dokümana dönüşebilir.

PostgreSQL ve MySQL Workshopları

Workshoplarda online index ve schema migration örnekleri çalışılabilir. Lock behavior karşılaştırılır. Binlog ve WAL kavramları uygulamalı görülür. Participant kendi migration script'ini yazabilir. Dry-run ve rollback zorunlu adım yapılabilir.

CDC Laboratuvarları

PostgreSQL veya MySQL change stream bir target database'e taşınabilir. Lag dashboard oluşturulur. Connector kasıtlı durdurulur. Log retention problemi gözlemlenir. Recovery sonrası catch-up ölçülür.

Zero-Downtime Migration Game Day

Katılımcılar source ve target database arasında canlı cutover simülasyonu yapabilir. Bir ekip migration, diğer ekip incident rolünü üstlenebilir. Hedef database kasıtlı bozulabilir. Rollback runbook uygulanır. Sonrasında teknik retrospektif yapılır.

Open Source ve İşbirliği Çalışmaları

Migration tooling issue'ları birlikte incelenebilir. Test veya documentation contribution seçilebilir. Pull request review grup halinde yapılabilir. Benchmark sonucu paylaşılabilir. Bu süreç işbirliği ve teknik iletişimi güçlendirir.

Diyarbakır'daki En İyi Yazılımcılarla Teknik Deneyim Paylaşımı

Farklı seviyelerdeki geliştiricilerin aynı migration problemi üzerinde çalışması çeşitli çözüm yollarını görünür kılar. Backend, DevOps ve database perspektifleri bir araya gelir. Gerçek incident örnekleri anonimleştirilerek değerlendirilebilir. Ortak runbook standardı geliştirilebilir. Teknik deneyim paylaşımı bölgesel ekosistemin üretim kalitesini artırır.

Ortak Proje Fikirleri

Ortak projeler yalnız demo değil, ölçülebilir failure ve recovery hedefi taşımalıdır. Her projede monitoring ve rollback bulunabilir. Git repository üzerinden issue ve review süreci kurulabilir. Katılımcılar farklı roller üstlenebilir. Sonuçlar topluluk içinde yeniden kullanılabilir öğrenme materyaline dönüşür.

PostgreSQL Schema Migration Lab

Büyük örnek tabloda nullable kolon eklenebilir. Batched backfill uygulanır. Concurrent index oluşturulur. Feature flag ile read path değiştirilir. Son aşamada contract migration çalıştırılır.

MySQL gh-ost Laboratuvarı

Hot table üzerinde ghost migration simüle edilebilir. Binlog tracking izlenir. Throttling davranışı test edilir. Cutover öncesi failure oluşturulur. Recovery runbook birlikte uygulanır.

Debezium CDC Projesi

Source database değişiklikleri Kafka üzerinden target'a taşınabilir. Connector offset izlenir. Consumer idempotent yazılır. Mismatch validation eklenir. Replay senaryosu test edilir.

Cloud Database Migration Pilot Projesi

Local database cloud target'a taşınabilir. Full load ve CDC birlikte çalıştırılır. Shadow read uygulanır. Canary traffic target'a alınır. Source grace period sonunda kapatılır.

Sık Sorulan Sorular

Veritabanı migration süreçlerinde en sık sorulan sorular kesinti, veri senkronizasyonu ve rollback etrafında toplanır. Zero downtime yaklaşımının temelinde compatibility window, continuous synchronization ve validation vardır. Cutover yalnız son trafik yönlendirme adımıdır. Güvenli migration, haftalar sürebilen hazırlık ve doğrulama sürecidir. Aşağıdaki cevaplar production kararlarını kısa ve uygulanabilir biçimde özetler.

Zero-downtime database migration nedir?

Zero-downtime migration kullanıcı trafiğini planlı olarak durdurmadan database geçişi yapmayı hedefler. Source ve target bir süre birlikte çalışır. Data sürekli senkronize edilir. Trafik kademeli target'a alınır. Rollback seçeneği son ana kadar korunur.

Veritabanı kesinti olmadan taşınabilir mi?

Evet, uygun architecture ve migration tooling ile planned outage olmadan taşınabilir. Ancak absolute zero error garantisi gerçek distributed sistemlerde ayrıca değerlendirilmelidir. Kullanıcı etkisi SLO ile ölçülmelidir. CDC ve phased cutover riski azaltır. Application compatibility temel gereksinimdir.

Expand-and-contract pattern nedir?

Breaking schema değişikliğini expand, migrate ve contract aşamalarına böler. Yeni yapı önce eski code'u bozmadan eklenir. Data ve application yeni yapıya taşınır. Eski yapı stability sonrası kaldırılır. Rollback penceresi bu sayede korunur.

Change Data Capture nedir?

CDC database transaction log'undaki değişiklikleri sürekli yakalar. Insert, update ve delete target sisteme aktarılır. Full load ile birlikte kullanılabilir. Replication lag izlenmelidir. Cutover öncesi target'ın güncel kalmasını sağlar.

CDC ile dual write arasındaki fark nedir?

CDC değişiklikleri database log seviyesinden yakalar. Dual write application'ın iki database'e write göndermesidir. CDC application coupling'i azaltabilir. Dual write partial failure riski taşır. Seçim transformation ve operasyon ihtiyacına göre yapılır.

Büyük database sıfır kesintiyle nasıl taşınır?

Önce initial full load yapılır. Ongoing changes CDC ile yakalanır. Historical data batch ve parallel yöntemle taşınabilir. Target validation ve shadow read ile test edilir. Trafik canary aşamalarıyla kademeli geçirilir.

PostgreSQL migration sırasında tablo kilitlenir mi?

Bazı DDL işlemleri güçlü lock alabilir. Lock seviyesi yapılan değişikliğe bağlıdır. Concurrent ve staged teknikler blocking etkisini azaltır. lock_timeout koruma sağlar. Production öncesi gerçek sürüm ve veri hacminde test yapılmalıdır.

CREATE INDEX CONCURRENTLY ne işe yarar?

PostgreSQL'de index oluştururken normal write trafiğinin büyük ölçüde devam etmesini hedefler. Standard index build'e göre daha uzun sürebilir. CPU ve I/O tüketir. Failure invalid index bırakabilir. Son state kontrol edilmelidir.

MySQL ALGORITHM=INSTANT nedir?

Belirli ALTER işlemlerini data satırlarını yeniden yazmadan metadata seviyesinde uygulamayı amaçlar. Bu nedenle çok hızlı olabilir. Her schema değişikliği desteklenmez. Version farkları önemlidir. Production DDL öncesi behavior doğrulanmalıdır.

gh-ost nedir?

gh-ost MySQL online schema migration için ghost table kullanan araçtır. Existing data yeni table'a kopyalanır. Source değişiklikleri binlog üzerinden takip edilir. Throttle ve controlled cutover sağlar. Büyük hot table değişikliklerinde değerlendirilebilir.

pt-online-schema-change nedir?

Shadow table ve trigger tabanlı change capture kullanarak online schema değişikliği yapar. Data chunk halinde kopyalanır. Source write'lar trigger ile target'a aktarılır. Final swap yapılır. Trigger overhead production workload'da ölçülmelidir.

Backfill nasıl yapılmalıdır?

Backfill küçük batch'lerle çalışmalıdır. Job idempotent ve resumable olmalıdır. Checkpoint kullanılmalıdır. CPU, I/O ve replica lag üzerinden throttle uygulanmalıdır. Büyük tek transaction kullanılmamalıdır.

Migration sırasında veri doğruluğu nasıl kontrol edilir?

Row count ilk kontroldür. Checksum ve primary-key comparison daha güçlü sonuç verir. Business aggregate ve referential integrity ayrıca ölçülür. Shadow read gerçek query sonucunu karşılaştırır. Validation cutover boyunca devam etmelidir.

Shadow read nedir?

Kullanıcı cevabı source database'den verilir. Aynı read target üzerinde arka planda çalıştırılır. Sonuçlar ve latency karşılaştırılır. Kullanıcı target hatasından etkilenmez. Cutover öncesi gerçek traffic validation sağlar.

Blue-green database migration nedir?

Mevcut blue database ile yeni green database yan yana çalışır. Data sürekli senkronize edilir. Read traffic önce green üzerinde test edilir. Writer daha sonra green'e geçirilir. Blue rollback için grace period boyunca tutulur.

AWS DMS sıfır kesinti sağlar mı?

Full load ve CDC yetenekleri minimal planned downtime migration kurmaya yardımcı olabilir. Ancak application cutover ve connection yönetimini tek başına çözmez. Validation ayrıca gerekir. Target readiness ayrı test edilmelidir. Gerçek kullanıcı kesintisi tüm sistem davranışına bağlıdır.

Google Database Migration Service nasıl çalışır?

Desteklenen migration senaryolarında initial snapshot ve continuous replication kullanılabilir. Source değişiklikleri target'a aktarılır. Target source'a yetiştiğinde finalization yapılır. Application routing ayrı yönetilir. Engine ve region support kullanılan servis kapsamına göre doğrulanmalıdır.

Rollback nasıl yapılır?

Read routing source'a hızlı döndürülebilir. Writer target'a geçtiyse source'un güncel kalması gerekir. Reverse CDC veya data reconciliation gerekebilir. Application version eski schema ile uyumlu olmalıdır. Rollback game day ile önceden test edilmelidir.

Migration sonrası eski database ne zaman kapatılmalıdır?

Cutover hemen sonrasında kapatılmamalıdır. Read-only grace period tutulmalıdır. Final reconciliation tamamlanmalıdır. Source'a connection kalmadığı doğrulanmalıdır. Backup ve audit sonrasında decommission yapılabilir.

Database migration için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. SQL temel gereksinimdir. Python, Go veya TypeScript automation için kullanılabilir. Existing platform ve ekip deneyimi önemlidir. Database ve distributed systems bilgisi dilden daha değerlidir.

Yazılımcı olmak için database migration öğrenmek gerekli midir?

Her yazılımcının uzman migration engineer olması gerekmez. Ancak schema compatibility, transaction ve rollback bilgisi backend geliştirmede çok değerlidir. Production database değişiklikleri birçok projede kaçınılmazdır. Bu bilgi güvenli deployment yeteneğini artırır. Senior backend rolünde özellikle önem kazanır.

Open source ve işbirliği database kariyerine nasıl katkı sağlar?

Gerçek issue ve code review production edge case'lerini görmeyi sağlar. Migration tooling'in tasarım kararları incelenebilir. Pull request teknik iletişim becerisini geliştirir. Ortak lab ve runbook paylaşımı deneyimi hızlandırır. Açık kaynak katkısı güçlü teknik portföy oluşturabilir.

Veritabanı taşıma (Migration) süreçlerinde sıfır kesinti nasıl sağlanır?

Veritabanı Taşıma (Migration) Süreçlerinde Sıfır Kesinti Taktikleri tek bir cutover komutuna dayanmaz. Önce source ve target compatibility sağlanır, ardından historical data full load veya backfill ile taşınır. Yeni write'lar CDC veya güvenilir senkronizasyonla target'a aktarılır. Validation geçtikten sonra read ve write trafiği feature flag veya proxy ile kademeli değiştirilir. Rollback için source database ve eski schema stability window boyunca korunur.

Zero-Downtime veritabanı taşımasında replikasyon ve Change Data Capture (CDC) nasıl kullanılır?

Replication veya CDC source transaction log'undaki değişiklikleri target database'e sürekli aktarır. Initial full load historical data'yı taşırken CDC migration sırasında oluşan yeni write'ları yakalar. Target apply kapasitesi source write throughput'unu karşılamalıdır. Replication lag cutover için temel quality gate olarak izlenir. Writer target'a ancak target source'a yeterince yaklaştığında geçirilmelidir.

Veritabanı migration işlemlerinde veri tutarlılığı ve senkronizasyon nasıl doğrulanır?

Source ve target row count, checksum ve primary-key seviyesinde karşılaştırılmalıdır. Kritik kolonlar için value mismatch rate ölçülebilir. Referential integrity ve business totals ayrıca doğrulanmalıdır. Shadow read gerçek production query sonuçlarını karşılaştırmaya yardım eder. Validation yalnız cutover öncesinde değil migration boyunca sürekli çalışmalıdır.

Sıfır kesintili veritabanı geçişlerinde cutover rollback ve schema değişiklikleri nasıl yönetilmelidir?

Schema değişiklikleri expand-and-contract modeliyle küçük ve backward-compatible adımlara bölünmelidir. Read cutover genellikle writer değişikliğinden önce yapılmalıdır. Writer switch sırasında single writer ve fencing uygulanmalıdır. Rollback feature flag, source grace period ve gerekiyorsa reverse CDC ile desteklenmelidir. Destructive schema değişiklikleri stability window bitene kadar ertelenmelidir.

Veritabanı taşıma ve Zero-Downtime Migration konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Veritabanı migration ve DBA danışmanlığı yakınımda şeklindeki aramalarda uygulamalı laboratuvar, gerçek cutover provası ve rollback deneyimi sunan teknik çalışmalar öncelikli değerlendirilebilir. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects üzerinden ulaşabilirsiniz. Topluluk hakkında ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Kurumsal zero downtime veritabanı migration ve taşıma hizmeti değerlendirilirken yalnız data copy değil, CDC lag, validation, rollback ve application compatibility süreçlerinin tamamının kapsanmasına dikkat edilmelidir. En verimli eğitim modeli gerçekçi bir source-target ortamında failure scenario oluşturarak migration ve geri dönüş süreçlerini birlikte uygulamaktır.

Sonuç: Gerçek Sıfır Kesinti Bir Cutover Hilesi Değil, Aşamalı Bir Süreçtir

Veritabanı Taşıma (Migration) Süreçlerinde Sıfır Kesinti Taktikleri doğru uygulandığında migration'ı riskli bir gece operasyonundan kontrollü bir production deployment sürecine dönüştürür. En önemli fikir, yeni database'i bir anda source of truth yapmak yerine compatibility, synchronization, validation ve canary aşamalarından geçirmektir. Database migration sürecinde blue green deployment CDC ve rollback stratejileri birlikte düşünüldüğünde tek bir failure'ın tüm kullanıcıları etkileme ihtimali ciddi biçimde azalır. Teknik ekip migration hızından önce veri tutarlılığını, application availability'yi ve geri dönüş kolaylığını korumalıdır. Database engineering, zero downtime migration ve backend altyapı çalışmaları için Diyarbakır Yazılım Topluluğu'nu https://www.diyarbakiryazilim.com.tr üzerinden takip edebilirsiniz.

Breaking Değişiklikleri Küçük ve Geri Döndürülebilir Adımlara Bölün

Büyük tek migration yerine expand, migrate ve contract aşamaları kullanılmalıdır. Her aşamanın sonucu ayrı doğrulanır. Failure scope küçük kalır. Rollback daha kolay olur. Production ekibi değişikliğin etkisini daha net görebilir.

Eski ve Yeni Sistemleri Compatibility Window Boyunca Birlikte Çalıştırın

Eski application version hemen geçersiz hale getirilmemelidir. Source ve target kısa süre birlikte bulunabilir. Schema iki version'ı desteklemelidir. Rolling deployment güvenli olur. Stability kanıtlandıktan sonra eski yapı kaldırılır.

Geçmiş Veriyi Idempotent Batch'lerle Taşıyın

Historical backfill tek transaction olmamalıdır. Batch küçük ve tekrar çalıştırılabilir olmalıdır. Checkpoint progress'i korur. Throttling production SLO'yu korur. Crash recovery manual temizliğe ihtiyaç duymamalıdır.

Yeni Değişiklikleri CDC veya Güvenilir Senkronizasyonla Aktarın

Full load tek başına yeterli değildir. Migration boyunca yeni source write'lar devam eder. CDC bu değişiklikleri transaction log'dan yakalayabilir. Dual write kullanılıyorsa idempotency şarttır. Target freshness lag metriğiyle izlenmelidir.

Cutover Öncesinde Veriyi Sürekli Doğrulayın

Validation migration'ın son dakikasına bırakılmamalıdır. Row count ve checksum sürekli çalışabilir. Shadow read production query behavior'unu test eder. Business total teknik veriyi domain doğruluğuna bağlar. Mismatch trendi cutover kararını yönlendirmelidir.

Trafiği Feature Flag ve Canary ile Kademeli Taşıyın

Internal kullanıcılarla başlanabilir. Sonra küçük gerçek traffic target'a yönlendirilir. Error ve p99 her aşamada kontrol edilir. Writer switch en son yapılır. Sorunda feature flag hızlı rollback sağlar.

Rollback Kolaylığını Son Ana Kadar Koruyun

Source database hemen kapatılmamalıdır. Destructive schema değişikliği ertelenmelidir. Reverse CDC gerekiyorsa kısa süre tutulur. Application eski schema ile çalışabilmelidir. Point of no return mümkün olduğunca geç tutulmalıdır.

Eski Database'i Doğrulama Süresi Dolmadan Kapatmayın

Cutover başarısı ilk on dakikada kesinleşmez. Bazı edge case'ler günler sonra görülebilir. Source read-only olarak tutulabilir. Final reconciliation tamamlanmalıdır. Decommission ayrı onay aşamasına sahip olmalıdır.

Migration'ı Tek Seferlik SQL Değil Production Deployment Sistemi Olarak Tasarlayın

Migration tekrar üretilebilir automation ve runbook ile yönetilmelidir. CI riskli DDL'i yakalamalıdır. Dashboard progress ve quality metric'i göstermelidir. Game day rollback becerisini doğrulamalıdır. Böyle bir sistem yalnız tek migration'ı değil, sonraki tüm database değişikliklerini daha güvenli hale getirir.