変更追跡(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 ログに基づいて変更を追跡する。LogMiner は REDO/アーカイブログを SQL に変換して過去の DML を調査する。分析対象のログファイルは DBMS_LOGMNR.ADD_LOGFILE で追加する。意味のある結果を得るには、少なくとも最小限のサプリメンタルロギングを有効にする必要がある(ALTER DATABASE ADD SUPPLEMENTAL LOG DATA)。継続的で低レイテンシの CDC と異種間レプリケーションには Oracle GoldenGate(別製品)が標準。旧来の Streams/Change Data Capture 機能は非推奨。

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 の論理デコーディングは、出力プラグイン(wal2json、pgoutput、test_decoding)を通じて WAL レコードを読み取り可能な変更ストリームに変換する。レプリケーションスロットが変更の損失を防ぐ。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 のソースはバイナリログ。binlog_format=ROW ではすべての行の変更が記録される。Debezium や Maxwell などのツールはレプリカのように 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 は 2 つの仕組みを提供する。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 イベントをリアルタイムのストリームとして配信する。レプリカセットまたはシャードクラスタが必要。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 のキースペース通知は、キーに対するイベント(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 で開く →