Multi-Database CDC Architecture

В предыдущих уроках модуля 7 вы проектировали CDC pipeline для одного источника — PostgreSQL или MySQL. В реальных enterprise системах часто требуется объединять события из нескольких баз данных в единый аналитический поток.

Этот урок показывает, как строить multi-database CDC architecture — объединять PostgreSQL и MySQL в одном Debezium deployment, управлять различиями в position tracking, schema history, и мониторинге.

Зачем нужен Multi-Database CDC?

Реальные сценарии

Сценарий 1: Разные команды владеют разными базами данных

Типичная enterprise архитектура:

• Team Orders: Использует PostgreSQL для заказов (выбрали из-за JSONB и extensibility)
• Team Inventory: Использует MySQL для складских остатков (legacy система, миграция дорогая)
• Team Analytics: Нужны события из обеих систем в BigQuery для unified reporting

Проблема: Если строить два изолированных CDC pipeline, аналитическая команда получает:

• Два набора Kafka topics
• Два формата events (разные metadata, envelope structures)
• Сложность в join операциях через источники

Решение: Multi-database CDC pipeline с унифицированной архитектурой.

Сценарий 2: Polyglot Persistence + Legacy Integration

Многие компании используют polyglot persistence — разные СУБД для разных workloads:

• PostgreSQL для transactional workloads (ACID guarantees)
• MySQL для read-heavy workloads (legacy application, не хотят переписывать)
• Cassandra для time-series data

CDC нужен для real-time analytics cross-database — объединить заказы (PostgreSQL) с inventory (MySQL) в реальном времени.

Сценарий 3: Migrация между СУБД

При миграции с MySQL на PostgreSQL (или наоборот):

• Dual-write phase: Приложение пишет в обе базы
• Validation phase: CDC от обеих баз для сравнения консистентности
• Cutover phase: Переключиться на новую базу, оставить старую read-only

CDC помогает: Проверить, что migration не потерял данные через comparison streams.

Архитектурные паттерны

Существует два основных подхода к multi-database CDC:

Pattern 1: Separate Topics Architecture

Каждая база данных публикует события в database-specific topics.

Naming Convention:

postgres_prod.public.orders         # PostgreSQL connector topic
mysql_prod.inventory.stock          # MySQL connector topic
mysql_prod.schema_history           # MySQL schema history topic (PostgreSQL doesn't need this)

Характеристики:

Когда использовать:

• ✅ Learning и initial implementation (easier to understand)
• ✅ Different schemas в PostgreSQL vs MySQL (нельзя объединить в одну структуру)
• ✅ Different aggregates (orders vs inventory — conceptually different)
• ✅ Independent schema evolution (PostgreSQL team и MySQL team работают независимо)

Pattern 2: Unified Topics Architecture

Использует ByLogicalTableRouter SMT для объединения событий из обеих баз в single topic per aggregate.

SMT Configuration Example:

{
  "name": "postgres-outbox-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.server.name": "postgres_prod",

    "transforms": "outbox,router",
    "transforms.outbox.type": "io.debezium.transforms.outbox.EventRouter",
    "transforms.outbox.route.by.field": "aggregatetype",

    "transforms.router.type": "io.debezium.transforms.ByLogicalTableRouter",
    "transforms.router.topic.regex": "postgres_prod\\.public\\.outbox",
    "transforms.router.topic.replacement": "outbox.event.orders"
  }
}

Характеристики:

Когда использовать:

• ✅ Identical schemas в PostgreSQL и MySQL (same columns, same types)
• ✅ Outbox Pattern в обеих базах (aggregatetype роутит события)
• ✅ Consumer preference для single stream (проще обработка)
• ⚠️ Требует careful key design — добавить source_database prefix к key для уникальности

Comparison: Separate vs Unified

Decision Matrix

Рекомендация для capstone:

Используйте Separate Topics architecture:

• Проще для understanding (clear source attribution)
• Легче debug (isolated connector failures)
• Не требует координации schema changes между командами
• Более реалистичен для enterprise (разные команды владеют PostgreSQL vs MySQL)

Operational Differences: PostgreSQL vs MySQL

При работе с multi-database CDC критически важно понимать operational differences между connectors.

Schema Storage

Почему это важно:

PostgreSQL Connector:

{
  "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
  "database.server.name": "postgres_prod"
  // NO schema.history.topic — not needed
}

MySQL Connector:

{
  "connector.class": "io.debezium.connector.mysql.MySqlConnector",
  "database.server.name": "mysql_prod",
  "database.server.id": "184054",
  "schema.history.internal.kafka.topic": "mysql_prod.schema_history"  // REQUIRED
}

Position Tracking

Impликации:

PostgreSQL:

• Abandoned connector → replication slot остается active=false → WAL bloat → disk full
• Recovery: Переподключиться к существующему slot
• Мониторинг: SELECT * FROM pg_replication_slots WHERE active=false

MySQL:

• Abandoned connector → binlog purges after binlog_expire_logs_seconds → recovery impossible
• Recovery: Resnapshot если offset за пределами gtid_purged
• Мониторинг: Compare connector offset GTID vs SHOW MASTER STATUS

Recovery Procedures

Recovery time comparison:

PostgreSQL failover: ~5-10 minutes (slot migration complex)
MySQL failover: ~30 seconds (GTID automatic)

PostgreSQL schema change: No separate recovery needed
MySQL schema history corruption: Hours (resnapshot) or minutes (restore backup)

Monitoring Metrics

Unified monitoring dashboard должен показывать:

PostgreSQL Connector:
  - Replication lag: 45 MB
  - Slot active: true
  - Last event: 2s ago

MySQL Connector:
  - MilliSecondsBehindSource: 350 ms
  - Current GTID: ...62:1-5429
  - Schema history topic: 1.2 MB (OK)
  - Binlog retention: 5.3 days remaining

Critical Pitfalls: Unique Identifiers

При multi-database CDC каждый connector ОБЯЗАН иметь unique identifiers для предотвращения конфликтов.

Required Unique Properties

Topic Naming Collision Example

Проблема: Если оба connector используют одинаковый database.server.name:

// PostgreSQL connector
{"database.server.name": "prod"}  // Topic: prod.public.orders

// MySQL connector
{"database.server.name": "prod"}  // Topic: prod.inventory.orders

Result: Если table names совпадают (orders), topics collide → события смешиваются → data corruption.

Решение:

// PostgreSQL connector
{"database.server.name": "postgres_prod"}  // Topic: postgres_prod.public.orders

// MySQL connector
{"database.server.name": "mysql_prod"}     // Topic: mysql_prod.inventory.orders

Multi-Database Configuration Template

PostgreSQL Connector

{
  "name": "postgres-prod-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "postgres.example.com",
    "database.port": "5432",
    "database.user": "debezium_user",
    "database.password": "secure_password",
    "database.dbname": "orders_db",
    "database.server.name": "postgres_prod",

    "plugin.name": "pgoutput",
    "slot.name": "debezium_pg_orders_slot",
    "publication.autocreate.mode": "filtered",

    "table.include.list": "public.orders,public.order_items",
    "heartbeat.interval.ms": "10000",
    "snapshot.mode": "when_needed"
  }
}

MySQL Connector

{
  "name": "mysql-prod-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "mysql.example.com",
    "database.port": "3306",
    "database.user": "debezium_user",
    "database.password": "secure_password",
    "database.server.name": "mysql_prod",
    "database.server.id": "184054",

    "table.include.list": "inventory.stock,inventory.warehouses",
    "schema.history.internal.kafka.topic": "mysql_prod.schema_history",
    "schema.history.internal.kafka.bootstrap.servers": "kafka:9092",

    "gtid.source.includes": ".*",
    "heartbeat.interval.ms": "10000",
    "snapshot.mode": "when_needed",
    "binlog.row.metadata.enabled": "true"
  }
}

Key Links

Module 2: PostgreSQL CDC Foundations

• Logical Decoding Deep Dive — Понимание replication slots и LSN tracking
• Replication Slot Management — Slot lifecycle и WAL bloat prevention

Module 8: MySQL CDC Foundations

• GTID Mode Fundamentals — Понимание GTID vs binlog file:position
• Binlog vs WAL Comparison — Архитектурные различия PostgreSQL vs MySQL
• Schema History Recovery — MySQL schema history topic backup и recovery
• Multi-Connector Deployments — database.server.id registry и unique identifier management

Next Lesson:

• Multi-Database Configuration — Hands-on implementation паттернов из этого урока

Ключевые выводы

1. Multi-database CDC реален: Enterprise часто требует объединения PostgreSQL и MySQL в единый analytics stream
2. Два паттерна: Separate Topics (recommended for learning) vs Unified Topics (advanced, requires identical schemas)
3. Separate Topics = easier: Independent schema evolution, clear traceability, simpler troubleshooting
4. Unified Topics = complex: Requires ByLogicalTableRouter SMT, careful key design, coordinated schema changes
5. Schema storage различается: PostgreSQL embeds schema in WAL, MySQL uses schema.history.internal.kafka.topic
6. Position tracking различается: PostgreSQL = server-side slots, MySQL = client-side GTID offsets
7. Recovery procedures различаются: PostgreSQL slot migration vs MySQL GTID auto-relocation
8. NEVER share schema history topics между MySQL connectors (causes DDL pollution)
9. Unique identifiers MANDATORY: database.server.name, database.server.id, schema.history.topic must be unique
10. Monitoring = unified dashboard: Show PostgreSQL lag (bytes) + MySQL lag (milliseconds) + schema history health

В следующем уроке: Hands-on implementation multi-database CDC pipeline с PostgreSQL + MySQL в capstone проекте.