DBAtlas · Atlas de operaciones de bases de datos

Seguimiento de cambios (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 hace el seguimiento de cambios basándose en el redo log. LogMiner traduce los redo/archived logs a SQL para inspeccionar DML pasado; los archivos de log que se analizarán se añaden con DBMS_LOGMNR.ADD_LOGFILE. Para obtener resultados significativos, debe estar habilitado al menos el supplemental logging mínimo (ALTER DATABASE ADD SUPPLEMENTAL LOG DATA). Para CDC continuo y de baja latencia y replicación heterogénea, el estándar es Oracle GoldenGate (un producto aparte); las antiguas funciones Streams/Change Data Capture están obsoletas.

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);

El logical decoding de PostgreSQL convierte los registros del WAL en un flujo de cambios legible mediante un output plugin (wal2json, pgoutput, test_decoding); el replication slot garantiza que no se pierdan cambios. wal_level debe ser logical. Debezium usa este mecanismo para ofrecer CDC empresarial.

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.

En MySQL, la fuente de CDC es el binary log. Con binlog_format=ROW se registra cada cambio de fila. Herramientas como Debezium o Maxwell leen el binlog como una réplica y generan un flujo de eventos hacia Kafka. Habilitar GTID facilita un seguimiento fiable de la posición.

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 ofrece dos mecanismos: Change Data Capture (CDC) escribe todo el DML (con valores antiguos/nuevos) desde el log de transacciones en tablas de cambios y requiere SQL Server Agent. Change Tracking solo registra de forma ligera qué filas cambiaron (cambios netos) y no conserva un historial completo de los datos.

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()); }

MongoDB Change Streams, construidos sobre el oplog, entregan los eventos insert, update y delete a nivel de colección/base de datos/clúster como un flujo en tiempo real. Requiere un replica set o un sharded cluster. Con un resumeToken, un flujo puede reanudarse donde lo dejó tras una interrupción; es la base de las integraciones de 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

Las keyspace notifications de Redis publican eventos sobre las claves (SET, DEL, EXPIRE, etc.) a través de canales Pub/Sub; se habilitan con la opción notify-keyspace-events (K=keyspace, E=keyevent, A=todos los eventos). Para un flujo de cambios fiable y durable, se prefieren Redis Streams (XADD/XREAD).

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 no ofrece un flujo de captura de cambios (CDC); no publica de forma nativa cuándo cambió un documento. El enfoque habitual es añadir un campo updated_ts a cada documento y ejecutar consultas incrementales por marca de tiempo (range + sort). Normalmente se alimenta Elasticsearch con el CDC de la base de datos de origen.

Abrir en DBAtlas →