DBAtlas · Veritabanı operasyon atlası

Sürekli çoğaltma / CDC kur (kesintisiz geçiş)

Oracle

# Oracle GoldenGate ile CDC tabanlı çoğaltma (özet akış)
# 1) Kaynakta supplemental logging aç:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
# 2) Extract (redo'dan değişiklik yakala) ve Replicat (hedefe uygula) süreçleri:
#   GGSCI> ADD EXTRACT ext1, INTEGRATED TRANLOG, BEGIN NOW
#   GGSCI> ADD REPLICAT rep1, INTEGRATED
# Alternatif: Data Pump ile ilk yük + GoldenGate ile artımlı yakalama

Oracle'da kesintisiz/heterojen CDC için standart araç Oracle GoldenGate'tir: Extract süreci redo loglarından değişiklikleri yakalar, Replicat hedefe uygular; supplemental logging açık olmalıdır. Tipik göç: Data Pump ile ilk yük alınır, aradan itibaren GoldenGate değişiklikleri hedefe akıtarak neredeyse sıfır kesintiyle geçişi sağlar.

PostgreSQL

-- Kaynak (publisher): yayın oluştur (wal_level=logical olmalı)
CREATE PUBLICATION goc_yayin FOR ALL TABLES;

-- Hedef (subscriber): abonelik oluştur (ilk kopya + sürekli akış)
CREATE SUBSCRIPTION goc_abone
  CONNECTION 'host=kaynak dbname=magaza user=repl password=***'
  PUBLICATION goc_yayin;

PostgreSQL yerleşik logical replication ile CDC sağlar: kaynakta CREATE PUBLICATION, hedefte CREATE SUBSCRIPTION. Abonelik başlarken var olan veriyi kopyalar (initial copy) sonra WAL'den değişiklikleri sürekli akıtır; wal_level=logical gerekir. Büyük/karmaşık senaryolarda pglogical veya Debezium tercih edilir.

MySQL

-- Kaynak: binlog açık ve ROW formatında olmalı (log_bin, binlog_format=ROW)
-- Replikasyon kullanıcısı ver: GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

-- Hedefte kaynağı tanımla (ilk yükteki binlog konumundan başla):
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='kaynak', SOURCE_USER='repl', SOURCE_PASSWORD='***',
  SOURCE_LOG_FILE='binlog.000001', SOURCE_LOG_POS=1547;
START REPLICA;

MySQL'de kesintisiz geçiş binlog tabanlı replikasyonla yapılır. İlk yük mysqldump --source-data ile alınıp binlog konumu/GTID öğrenilir; hedefte CHANGE REPLICATION SOURCE TO ile bu konumdan başlatılır (8.0.23+ söz dizimi; eski adı CHANGE MASTER TO). START REPLICA ile değişiklikler sürekli uygulanır. GTID tabanlı kurulum daha güvenlidir.

SQL Server

-- Seçenek A: Transactional Replication (yayıncı->dağıtıcı->abone) — SSMS sihirbazı

-- Seçenek B: Change Data Capture (değişiklikleri tablo olarak izle)
EXEC sys.sp_cdc_enable_db;              -- veritabanı düzeyinde CDC aç
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'musteri',
  @role_name = NULL;                    -- tablo düzeyinde CDC aç
-- Değişiklikler cdc.dbo_musteri_CT tablosundan okunup hedefe taşınır.

SQL Server'da sürekli çoğaltma için iki ana yol vardır: hedefe doğrudan akış isteniyorsa Transactional Replication (yayıncı/abone) kurulur; değişiklikleri kendi ETL'inizle taşıyacaksanız Change Data Capture açılır (sp_cdc_enable_db + sp_cdc_enable_table) ve _CT tablolarından okunur. Heterojen hedeflerde CDC + AWS DMS/Debezium birlikte kullanılır.

MongoDB

// Change Streams ile değişiklikleri canlı izle (replica set/sharded gerekir)
const cs = db.musteri.watch([], { fullDocument: "updateLookup" });
while (cs.hasNext()) { printjson(cs.next()); }  // hedefe uygula

// Küme-küme yönetilen çoğaltma/geçiş için resmi araç: mongosync
// mongosync --cluster0 "mongodb://kaynak" --cluster1 "mongodb://hedef"

MongoDB'de CDC için Change Streams kullanılır: db.collection.watch() oplog üzerinden ekleme/güncelleme/silme olaylarını canlı akıtır ve hedefe uygulanır (replica set şarttır). Tam küme-küme sürekli geçiş/çoğaltma için MongoDB'nin resmi Cluster-to-Cluster Sync aracı mongosync (Atlas'a özgü değildir; self-managed kümelerde de çalışır) ilk yük + sürekli senkronizasyonu yönetir.

Redis

# Hedef instance'ı kaynağın replikası yap (canlı senkronizasyon)
# Hedef Redis'te:
REPLICAOF kaynak_host 6379
# Senkron durumunu izle:
INFO replication   # master_link_status:up olmalı

# Geçişi tamamlayınca hedefi bağımsızlaştır:
REPLICAOF NO ONE

Redis'te kesintisiz geçiş yerel replikasyonla yapılır: hedef sunucuda REPLICAOF <kaynak host port> (eski adı SLAVEOF) çalıştırılır; hedef önce tam RDB'yi alır sonra komut akışıyla sürekli senkron kalır. INFO replication ile master_link_status:up doğrulanır, geçiş tamamlanınca REPLICAOF NO ONE ile hedef bağımsız hale getirilir.

Elasticsearch

# Aynı sürüm ailesinde eski kümeden yeniye artımlı yeniden indeksleme
POST _reindex?wait_for_completion=false
{ "source": { "remote": { "host": "http://eski:9200" }, "index": "musteri",
    "query": { "range": { "guncelleme": { "gt": "<son-cursor>" } } } },
  "dest": { "index": "musteri" } }

# Lisanslı özellik: Cross-Cluster Replication (CCR) — sürekli takip
# Hedef (follower) kümede: PUT /musteri/_ccr/follow { "remote_cluster": "eski", "leader_index": "musteri" }

Elasticsearch'te gerçek sürekli çoğaltma özelliği Cross-Cluster Replication'dır (CCR): hedef küme kaynaktaki leader index'i takip ederek değişiklikleri sürekli çeker (ticari/Platinum lisans gerektirir). Lisanssız senaryoda periyodik remote reindex ile (bir zaman/sıra alanına göre artımlı) yaklaşık sürekli senkron sağlanır.

DBAtlas'ta aç →