DBAtlas · Атлас эксплуатации баз данных

Отслеживание изменений (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. Для осмысленных результатов должно быть включено как минимум минимальное supplemental logging (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 превращает записи WAL в читаемый поток изменений через плагин вывода (wal2json, pgoutput, test_decoding); слот репликации гарантирует, что изменения не теряются. 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 предлагает два механизма: 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()); }

MongoDB Change Streams, построенные на oplog, доставляют события 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

Keyspace notifications в 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). Как правило, в Elasticsearch подаётся CDC исходной базы.

Открыть в DBAtlas →