Kontinuierliche Replikation / CDC einrichten (Umschaltung ohne Ausfallzeit)

Oracle

# CDC-based replication with Oracle GoldenGate (outline)
# 1) Enable supplemental logging on the source:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
# 2) Extract (capture changes from redo) and Replicat (apply to the target) processes:
#   GGSCI> ADD EXTRACT ext1, INTEGRATED TRANLOG, BEGIN NOW
#   GGSCI> ADD REPLICAT rep1, INTEGRATED
# Alternative: initial load with Data Pump + incremental capture with GoldenGate

In Oracle ist Oracle GoldenGate das Standardtool für CDC ohne Ausfallzeit bzw. heterogene CDC: Der Extract-Prozess erfasst Änderungen aus den Redo-Logs, Replicat wendet sie auf das Ziel an; Supplemental Logging muss aktiviert sein. Typische Migration: Die Erstbeladung erfolgt mit Data Pump, danach streamt GoldenGate die Änderungen ins Ziel, was eine Umschaltung mit nahezu null Ausfallzeit ermöglicht.

PostgreSQL

-- Source (publisher): create a publication (wal_level must be logical)
CREATE PUBLICATION migration_pub FOR ALL TABLES;

-- Target (subscriber): create a subscription (initial copy + continuous stream)
CREATE SUBSCRIPTION migration_sub
  CONNECTION 'host=source dbname=shop user=repl password=***'
  PUBLICATION migration_pub;

PostgreSQL bietet CDC mit eingebauter logischer Replikation: CREATE PUBLICATION auf der Quelle, CREATE SUBSCRIPTION auf dem Ziel. Beim Start kopiert die Subscription die vorhandenen Daten (Initial Copy) und streamt danach fortlaufend Änderungen aus dem WAL; wal_level=logical ist erforderlich. Für große/komplexe Szenarien werden pglogical oder Debezium bevorzugt.

MySQL

-- Source: binlog must be enabled and in ROW format (log_bin, binlog_format=ROW)
-- Grant a replication user: GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

-- Define the source on the target (start from the binlog position of the initial load):
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='source', SOURCE_USER='repl', SOURCE_PASSWORD='***',
  SOURCE_LOG_FILE='binlog.000001', SOURCE_LOG_POS=1547;
START REPLICA;

In MySQL erfolgt eine Umschaltung ohne Ausfallzeit per Binlog-basierter Replikation. Die Erstbeladung wird mit mysqldump --source-data erstellt und die Binlog-Position/GTID notiert; auf dem Ziel wird die Replikation ab dieser Position mit CHANGE REPLICATION SOURCE TO gestartet (Syntax ab 8.0.23; früher CHANGE MASTER TO). START REPLICA wendet Änderungen fortlaufend an. Ein GTID-basiertes Setup ist sicherer.

SQL Server

-- Option A: Transactional Replication (publisher->distributor->subscriber) — SSMS wizard

-- Option B: Change Data Capture (track changes as tables)
EXEC sys.sp_cdc_enable_db;              -- enable CDC at database level
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'customer',
  @role_name = NULL;                    -- enable CDC at table level
-- Changes are read from the cdc.dbo_customer_CT table and moved to the target.

SQL Server bietet zwei Hauptwege für kontinuierliche Replikation: Für einen direkten Stream ins Ziel richte Transactional Replication (Publisher/Subscriber) ein; willst du Änderungen mit eigenem ETL übertragen, aktiviere Change Data Capture (sp_cdc_enable_db + sp_cdc_enable_table) und lies aus den _CT-Tabellen. Für heterogene Ziele wird CDC mit AWS DMS/Debezium kombiniert.

MongoDB

// Watch changes live with Change Streams (requires a replica set/sharded cluster)
const cs = db.customer.watch([], { fullDocument: "updateLookup" });
while (cs.hasNext()) { printjson(cs.next()); }  // apply to the target

// Official tool for managed cluster-to-cluster replication/migration: mongosync
// mongosync --cluster0 "mongodb://source" --cluster1 "mongodb://target"

In MongoDB werden für CDC Change Streams genutzt: db.collection.watch() streamt insert-/update-/delete-Ereignisse live aus dem Oplog, die auf das Ziel angewendet werden (ein Replica Set ist erforderlich). Für vollständige kontinuierliche Migration/Replikation von Cluster zu Cluster verwaltet mongosync, MongoDBs offizielles Tool Cluster-to-Cluster Sync (nicht Atlas-spezifisch; funktioniert auch mit selbst verwalteten Clustern), Erstbeladung + kontinuierliche Synchronisation.

Redis

# Make the target instance a replica of the source (live synchronization)
# On the target Redis:
REPLICAOF source_host 6379
# Monitor sync status:
INFO replication   # master_link_status must be up

# Once the cutover is complete, make the target standalone:
REPLICAOF NO ONE

In Redis erfolgt eine Umschaltung ohne Ausfallzeit mit nativer Replikation: Führe auf dem Zielserver REPLICAOF <source host port> aus (früher SLAVEOF); das Ziel erhält zuerst die vollständige RDB und bleibt dann über den Befehlsstrom fortlaufend synchron. Prüfe master_link_status:up mit INFO replication und mache das Ziel nach abgeschlossener Umschaltung mit REPLICAOF NO ONE eigenständig.

Elasticsearch

# Incremental reindex from the old cluster to the new one within the same version family
POST _reindex?wait_for_completion=false
{ "source": { "remote": { "host": "http://old:9200" }, "index": "customer",
    "query": { "range": { "updated_at": { "gt": "<last-cursor>" } } } },
  "dest": { "index": "customer" } }

# Licensed feature: Cross-Cluster Replication (CCR) — continuous following
# On the target (follower) cluster: PUT /customer/_ccr/follow { "remote_cluster": "old", "leader_index": "customer" }

Die echte kontinuierliche Replikation in Elasticsearch ist Cross-Cluster Replication (CCR): Der Zielcluster folgt dem Leader-Index auf der Quelle und zieht Änderungen fortlaufend (erfordert eine kommerzielle/Platinum-Lizenz). Ohne Lizenz wird eine nahezu kontinuierliche Synchronisation per periodischem Remote Reindex erreicht (inkrementell, anhand eines Zeit-/Sequenzfelds).

In DBAtlas öffnen →