DBAtlas · Atlas d'exploitation des bases de données

Suivi des modifications (CDC / change tracking)

Oracle

-- Read changes from redo logs with LogMiner:
-- 1) Add the archived/redo log file to analyze:
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(
  LOGFILENAME => '/u01/arch/1_1234_1122334455.arc',
  OPTIONS => DBMS_LOGMNR.NEW);
-- 2) Start the session:
EXECUTE DBMS_LOGMNR.START_LOGMNR(
  OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
SELECT sql_redo, sql_undo FROM V$LOGMNR_CONTENTS
WHERE seg_name = 'ORDERS';
-- 3) When finished: EXECUTE DBMS_LOGMNR.END_LOGMNR;
-- For enterprise CDC/replication, Oracle GoldenGate is used.

Oracle suit les modifications à partir du redo log. LogMiner traduit les redo/archived logs en SQL pour examiner le DML passé ; les fichiers journaux à analyser sont ajoutés avec DBMS_LOGMNR.ADD_LOGFILE. Pour des résultats exploitables, au moins le supplemental logging minimal doit être activé (ALTER DATABASE ADD SUPPLEMENTAL LOG DATA). Pour un CDC continu à faible latence et la réplication hétérogène, Oracle GoldenGate (produit distinct) est la norme ; les anciennes fonctionnalités Streams/Change Data Capture sont dépréciées.

PostgreSQL

-- Create a logical replication (logical decoding) slot:
SELECT * FROM pg_create_logical_replication_slot(
  'cdc_slot', 'wal2json');
-- Consume changes as JSON:
SELECT data FROM pg_logical_slot_get_changes('cdc_slot', NULL, NULL);

Le logical decoding de PostgreSQL transforme les enregistrements WAL en flux de modifications lisible via un output plugin (wal2json, pgoutput, test_decoding) ; le replication slot garantit qu'aucune modification n'est perdue. wal_level doit valoir logical. Debezium utilise ce mécanisme pour fournir un CDC d'entreprise.

MySQL

-- The row-based binlog is the CDC source (binlog_format=ROW):
SHOW BINARY LOGS;
SHOW BINLOG EVENTS IN 'binlog.000042';
-- Usually Debezium/Maxwell reads the binlog and turns it into a stream.

Dans MySQL, la source du CDC est le binary log. Avec binlog_format=ROW, chaque modification de ligne est enregistrée. Des outils comme Debezium ou Maxwell lisent le binlog comme un réplica et produisent un flux d'événements vers Kafka. Activer GTID facilite un suivi de position fiable.

SQL Server

-- Enable Change Data Capture on the database and the table:
EXEC sys.sp_cdc_enable_db;
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'orders',
  @role_name = NULL;
-- For lightweight tracking: ALTER DATABASE ... SET CHANGE_TRACKING = ON;

SQL Server offre deux mécanismes : Change Data Capture (CDC) écrit tout le DML (avec anciennes/nouvelles valeurs) depuis le journal des transactions dans des tables de modifications et nécessite SQL Server Agent. Change Tracking suit seulement, de façon légère, quelles lignes ont changé (net changes) et ne conserve pas l'historique complet des données.

MongoDB

// Watch changes in real time with Change Streams:
const stream = db.orders.watch([
  { $match: { operationType: { $in: ["insert", "update"] } } }
]);
while (stream.hasNext()) { printjson(stream.next()); }

Les Change Streams de MongoDB, basés sur l'oplog, fournissent les événements insert, update et delete au niveau collection/base/cluster sous forme de flux temps réel. Nécessite un replica set ou un cluster shardé. Avec un resumeToken, un flux peut reprendre là où il s'était arrêté après une interruption ; c'est la base des intégrations CDC.

Redis

# Listen for key changes with keyspace notifications:
CONFIG SET notify-keyspace-events KEA
# Subscribe to changed keys via Pub/Sub:
PSUBSCRIBE __keyevent@0__:set
PSUBSCRIBE __keyevent@0__:expired

Les keyspace notifications de Redis publient des événements sur les clés (SET, DEL, EXPIRE, etc.) via des canaux Pub/Sub ; elles s'activent avec le réglage notify-keyspace-events (K=keyspace, E=keyevent, A=tous les événements). Pour un flux de modifications fiable et durable, les Redis Streams (XADD/XREAD) sont préférables.

Elasticsearch

-- Not applicable: there is no built-in CDC/change stream.
# Closest equivalent: incremental query on a timestamp field:
GET orders/_search
{ "query": { "range": { "updated_ts": { "gt": "2026-07-05T00:00:00" } } },
  "sort": [ { "updated_ts": "asc" } ] }

Elasticsearch n'offre pas de flux de change data capture (CDC) ; il ne publie pas nativement le moment où un document a changé. L'approche courante consiste à ajouter un champ updated_ts à chaque document et à exécuter des requêtes incrémentales par horodatage (range + sort). En général, le CDC de la base source alimente Elasticsearch.

Ouvrir dans DBAtlas →