변경 추적(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은 redo log를 기반으로 변경을 추적한다. LogMiner는 redo/아카이브 로그를 SQL로 변환해 과거 DML을 조사하며, 분석할 로그 파일은 DBMS_LOGMNR.ADD_LOGFILE로 추가한다. 의미 있는 결과를 얻으려면 최소한 minimal supplemental logging을 활성화해야 한다(ALTER DATABASE ADD SUPPLEMENTAL LOG DATA). 지속적이고 저지연인 CDC와 이기종 복제에는 Oracle GoldenGate(별도 제품)가 표준이며, 기존 Streams/Change Data Capture 기능은 deprecated되었다.

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

PostgreSQL logical decoding은 output plugin(wal2json, pgoutput, test_decoding)을 통해 WAL 레코드를 읽을 수 있는 변경 스트림으로 변환하며, replication slot이 변경 유실을 막는다. wal_level은 logical이어야 한다. Debezium은 이 메커니즘을 사용해 엔터프라이즈 CDC를 제공한다.

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.

MySQL에서 CDC 소스는 binary log다. binlog_format=ROW이면 모든 행 변경이 기록된다. Debezium이나 Maxwell 같은 도구는 replica처럼 binlog를 읽어 Kafka로 이벤트 스트림을 생성한다. GTID를 활성화하면 위치를 안정적으로 추적하기 쉬워진다.

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는 두 가지 메커니즘을 제공한다. Change Data Capture(CDC)는 트랜잭션 로그에서 모든 DML(이전/새 값 포함)을 변경 테이블에 기록하며 SQL Server Agent가 필요하다. Change Tracking은 어떤 행이 변경되었는지(순 변경)만 가볍게 추적하며 전체 데이터 이력은 보관하지 않는다.

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

oplog 기반의 MongoDB Change Streams는 컬렉션/데이터베이스/클러스터 수준의 insert, update, delete 이벤트를 실시간 스트림으로 전달한다. replica set 또는 샤딩된 클러스터가 필요하다. resumeToken을 사용하면 중단 후 이어서 스트림을 재개할 수 있으며, 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

Redis keyspace notification은 키에 대한 이벤트(SET, DEL, EXPIRE 등)를 Pub/Sub 채널로 발행하며, notify-keyspace-events 설정으로 활성화한다(K=keyspace, E=keyevent, A=모든 이벤트). 신뢰할 수 있고 영속적인 변경 스트림에는 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는 변경 데이터 캡처(CDC) 스트림을 제공하지 않으며, 문서가 변경된 시점을 기본적으로 발행하지 않는다. 일반적인 방법은 모든 문서에 updated_ts 필드를 추가하고 타임스탬프 기준 증분 쿼리(range + sort)를 실행하는 것이다. 보통은 소스 데이터베이스의 CDC를 Elasticsearch로 공급한다.

DBAtlas에서 열기 →