CDC neyi çözer, neyi çözmez?
CDC, kaynak veritabanında değişen satırların hedefe akmasını sağlar. Böylece ilk büyük kopya bittikten sonra hedef sistem kaynağa yetişmeye çalışır ve cutover anındaki kesinti küçülür.
Ama CDC her şeyi çözmez. Şema uyumsuzluğu, uygulama bağlantı dizesi değişimi, kullanıcı yetkileri, sequence değerleri ve son doğrulama hâlâ sizin planınızın parçasıdır. CDC yalnızca veri farkını azaltır; cutover disiplinini ortadan kaldırmaz.
- Kaynak PostgreSQL logical replication desteklemeli.
- wal_level logical olmalı.
- Publication oluşturma yetkisi gerekir.
- Hedefin kaynağa ağ erişimi olmalıdır.
- Cutover öncesi replication lag izlenmelidir.
Kaynakta neye bakılır?
Göç başlamadan önce kaynak veritabanının logical replication için uygun olup olmadığını görmek gerekir. Bu noktada sorun çıkarsa cutover günü değil, hazırlık gününde çıkması iyidir.
Logical replication ön kontrolü
SHOW wal_level; SHOW max_replication_slots; SHOW max_wal_senders; SELECT rolname, rolreplication FROM pg_roles WHERE rolname = current_user;
Publication örneği
CREATE PUBLICATION turkdb_migration_pub FOR ALL TABLES; SELECT pubname, puballtables FROM pg_publication WHERE pubname = 'turkdb_migration_pub';
Gerçek migration-runner kendi publication adını üretir; bu örnek mantığı göstermek içindir.
Lag sıfıra yaklaşmadan cutover yapmayın
Cutover kararı çoğu zaman teknik değil, iş kararıdır. Lag birkaç saniyeyse ve uygulama kısa süre yazmayı durdurabiliyorsa kesinti küçük kalır. Lag dakikalara çıkıyorsa önce neden yetişemediğini anlamak gerekir: büyük transaction, indeks eksikliği, ağ gecikmesi veya hedef kapasitesi.
İyi cutover akışı genellikle şudur: uygulamayı bakım moduna alın, yeni yazmayı durdurun, son lag değerini bekleyin, doğrulama sorgularını çalıştırın, uygulamayı hedef DSN’e çevirin, hataları izleyin.
Subscription durumunu okuma
SELECT subname, pid, received_lsn, latest_end_lsn, latest_end_time FROM pg_stat_subscription;
Cutover anı karar notu
cutover_icin_hazir = yeni_yazma_durdu && replication_lag_kabul_edilebilir && kritik_tablo_sayimlari_eslesiyor && hedef_dsn_uygulamada_hazir && rollback_penceresi_tanimli
Cutover sonrası unutulan küçük şeyler
PostgreSQL göçlerinde veri taşındıktan sonra bile küçük farklar sorun çıkarabilir. Sequence değerleri, extension durumu, kullanıcı yetkileri, connection pool ayarları ve uygulama migrationlarının hedefteki etkisi kontrol edilmelidir.
TürkDB hedefinde bağlantı, TLS, yedek ve PITR zemininin hedef clusterla birlikte gelmesi gerekir. Bu davranış pilotta doğrulanmalı; uygulama kodunun hedefe geçiş davranışını ve veri doğrulamasını yine sizin iş akışınız belirler.
Sequence değerlerini hızlı kontrol etme fikri
SELECT
schemaname,
sequencename,
last_value
FROM pg_sequences
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY schemaname, sequencename;