Göç aslında ne zaman zorlaşır?
Küçük bir test veritabanını taşımak kolaydır. Zor olan, kullanıcılar yazmaya devam ederken üretim verisini taşımaktır. O sırada iki gerçeklik aynı anda yaşanır: kaynak sistem hâlâ çalışır, hedef sistem ise ona yetişmeye çalışır.
Bu yüzden göç planında “veriyi nasıl kopyalarız?” sorusu tek başına yetmez. “Kopya ne kadar sürecek?”, “kopya sırasında kaynakta ne değişecek?”, “uygulamayı hangi anda hedefe döndüreceğiz?” ve “yanlış giderse hangi noktaya geri döneceğiz?” soruları da aynı masada olmalıdır.
- One-shot göç: veri belirli bir anda kopyalanır; küçük kesinti veya yazma durdurma penceresi gerekir.
- CDC/canlı senkron: ilk kopyadan sonra değişiklikler hedefe akar; cutover anındaki fark küçülür.
- Dosya yükleme: dump veya CSV ile kontrollü taşıma yapılır; veri hacmi ve şema uyumu önceden test edilmelidir.
- Geri dönüş: cutover başarısız olursa uygulama ve veri hangi noktaya dönecek, önceden yazılmalıdır.
Motorlara göre dürüst beklenti kurun
Her motorun göç hikâyesi aynı değildir. PostgreSQL tarafında native logical replication ile CDC gerçekçi bir seçenek olabilir. MySQL ve MongoDB için de teorik CDC dünyası vardır; ama ürün bunu canlı ortam kanıtı olmadan müşteri görünür modda açmıyorsa, yazıda da açılmış gibi davranmamak gerekir.
ClickHouse göçünde ise çoğu zaman kaynak tablolardan hedefe toplu veri çekme, tablo yapısını uyarlama ve analitik ingest akışını yeniden yönlendirme konuşulur. OLTP cutover ile OLAP veri taşıma aynı stres biçimine sahip değildir.
Göç yaklaşımı karar tablosu
PostgreSQL -> one-shot veya CDC/logical replication MySQL -> one-shot dump/geri yükleme, cutover penceresi gerekir MongoDB -> one-shot mongodump/mongorestore, doğrulama önemli ClickHouse -> INSERT SELECT / remoteSecure() ile tablo bazlı taşıma CSV/SQL -> dosya yükleme, şema ve encoding kontrolü gerekir
Amaç motorları eşitlemek değil, her birinin güvenilir göç yolunu açıkça seçmektir.
Cutover gününden önce prova yapın
Cutover günü ilk kez denenmemelidir. En az bir prova göçü yapılmalı; kopya süresi, doğrulama süresi, uygulama bağlantı değişikliği ve geri dönüş adımı saat saat ölçülmelidir. Bu prova sıkıcı görünür, ama gerçek gün geldiğinde ekibin panik seviyesini düşüren şey tam olarak budur.
Doğrulama yalnızca “job completed” yazısını görmek değildir. Kritik tabloların satır sayısı, örnek kayıtların checksum değeri, indekslerin varlığı ve uygulamanın hedefe bağlanması ayrı ayrı kontrol edilmelidir.
Basit satır sayımı ve örnek doğrulama
-- Kaynak ve hedefte aynı sorguları çalıştırın SELECT count(*) FROM orders; SELECT count(*) FROM customers; -- Kritik son kayıtlar hedefte var mı? SELECT id, updated_at FROM orders ORDER BY updated_at DESC LIMIT 20;
Cutover kontrol listesi
1. Kaynak son yedekleme/PITR noktası doğrulandı 2. Hedef bağlantı bilgisi uygulama ortamında hazır 3. Migration job durumu ve son senkron zamanı görüldü 4. Yazma trafiği durduruldu veya bakım modu açıldı 5. Son doğrulama sorguları çalıştırıldı 6. Uygulama hedef DSN'e geçirildi 7. Hata oranı, gecikme ve temel iş akışları izlendi 8. Rollback kararı için süre sınırı belirlendi
Rollback planı moral bozmaz, ekibi rahatlatır
Geri dönüş planı yazmak kötümserlik değildir. Tam tersine, cutover sırasında karar vermeyi kolaylaştırır. “Ne olursa geri döneriz?” sorusu önceden konuşulmazsa, gerçek olay anında herkes farklı bir eşiğe göre karar verir.
TürkDB tarafında hedeflenen göç deneyimi, ilerleme durumunun izlenmesi ve hedef clusterın ayrı bir varlık olarak hazırlanmasıdır. Bu yaklaşım pilotta doğrulanırsa, kaynak sistemi hemen silmek yerine cutover sonrası gözlem penceresi tanımlamayı daha sağlıklı hale getirir.
- Rollback eşiği: hata oranı, veri farkı, gecikme veya kritik akış hatası net tanımlanmalı.
- Gözlem penceresi: cutover sonrası ilk 30-60 dakika canlı metrikler izlenmeli.
- Kaynak koruma: kaynak veritabanı hemen silinmemeli; belirlenen süre boyunca salt okunur tutulmalı.
- İletişim: ürün, destek ve operasyon ekipleri aynı zaman çizelgesini görmeli.