Настройка Cloud SQL PostgreSQL для CDC

В Module 2 мы подробно изучили logical decoding в PostgreSQL. Теперь применим эти знания для настройки Cloud SQL — управляемого PostgreSQL от Google Cloud Platform.

Почему Cloud SQL для CDC?

Cloud SQL PostgreSQL — это полностью управляемая база данных с поддержкой logical replication. Основные преимущества:

• Автоматические бэкапы и point-in-time recovery
• Встроенная высокая доступность (HA)
• Автоматическое масштабирование хранилища
• Мониторинг и алертинг через Cloud Monitoring
• Безопасность: шифрование в покое и в транзите

Ключевое отличие от самостоятельно развернутого PostgreSQL:

• Нет прямого доступа к postgresql.conf
• Конфигурация через database flags (gcloud CLI или Console)
• Вместо wal_level=logical используется флаг cloudsql.logical_decoding

Архитектура CDC на Cloud SQL

Поток данных:

1. Транзакции записываются в WAL (Write-Ahead Log)
2. Logical decoding преобразует WAL в структурированные события
3. Replication slot хранит позицию чтения и управляет удалением WAL
4. Debezium Server читает события из слота и публикует в Pub/Sub

Шаг 1: Включение Logical Decoding

Cloud SQL не предоставляет доступ к файлу postgresql.conf, поэтому используем database flags.

Через gcloud CLI

gcloud sql instances patch your-instance-name \
  --database-flags=cloudsql.logical_decoding=on

Важно: После применения флага требуется перезагрузка инстанса. Планируйте maintenance window.

Через Google Cloud Console

1. Перейдите в Cloud SQL > Instances
2. Выберите ваш инстанс PostgreSQL
3. Нажмите Edit
4. Прокрутите до раздела Flags
5. Добавьте флаг: cloudsql.logical_decoding = on
6. Нажмите Save
7. Подтвердите перезагрузку инстанса

Проверка конфигурации

После перезагрузки подключитесь к базе данных и проверьте:

SHOW wal_level;

Ожидаемый результат:

 wal_level
-----------
 logical

Если результат replica или minimal, флаг не применился — проверьте статус инстанса и повторите шаги.

Шаг 2: Создание Replication User

Debezium требует пользователя с привилегией REPLICATION для создания replication slot и чтения WAL.

Создание пользователя с REPLICATION

CREATE USER debezium_user WITH REPLICATION
  IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secure_password_here';

Объяснение параметров:

Предоставление прав на таблицы

Debezium нужен доступ на чтение таблиц для initial snapshot и мониторинга схемы.

-- Права на существующие таблицы
GRANT SELECT ON ALL TABLES IN SCHEMA public TO debezium_user;

-- Права на будущие таблицы (автоматически)
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO debezium_user;

Для нескольких схем:

GRANT SELECT ON ALL TABLES IN SCHEMA public, inventory, orders TO debezium_user;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO debezium_user;

ALTER DEFAULT PRIVILEGES IN SCHEMA inventory
  GRANT SELECT ON TABLES TO debezium_user;

Шаг 3: Создание Publication

Publication определяет, какие таблицы и операции (INSERT, UPDATE, DELETE) будут реплицироваться.

Publication для конкретных таблиц

CREATE PUBLICATION debezium_publication
  FOR TABLE public.orders, public.customers;

Publication для всех таблиц в схеме

CREATE PUBLICATION debezium_publication
  FOR ALL TABLES;

Рекомендация: Используйте явный список таблиц для production, чтобы избежать случайной репликации служебных таблиц.

Проверка publication

-- Список всех publications
SELECT * FROM pg_publication;

-- Таблицы в конкретной publication
SELECT * FROM pg_publication_tables WHERE pubname = 'debezium_publication';

Ожидаемый результат:

     pubname          | schemaname | tablename
---------------------+------------+-----------
 debezium_publication | public     | orders
 debezium_publication | public     | customers

Шаг 4: Мониторинг Replication Slots

Критически важно: Неактивные или отстающие replication slots приводят к WAL bloat — накоплению WAL файлов, которые не могут быть удалены.

Запрос для мониторинга здоровья слота

SELECT
  slot_name,
  active,
  restart_lsn,
  confirmed_flush_lsn,
  pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS lag_bytes,
  pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots
WHERE slot_name = 'debezium_slot';

Интерпретация результатов:

Критические сигналы проблем

Проблема 1: Отставание растет

-- Если lag_bytes постоянно увеличивается
SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots
WHERE slot_name = 'debezium_slot';

Действия:

• Проверьте, работает ли Debezium Server
• Увеличьте ресурсы Cloud SQL instance (CPU, memory)
• Проверьте пропускную способность сети до Pub/Sub

Проблема 2: Слот неактивен

SELECT slot_name, active
FROM pg_replication_slots
WHERE slot_name = 'debezium_slot' AND active = false;

Действия:

• Если слот неактивен > 1 часа, выясните причину остановки Debezium
• Рассмотрите удаление слота, если больше не используется:

  SELECT pg_drop_replication_slot('debezium_slot');

Предотвращение WAL bloat

PostgreSQL 13+ поддерживает флаг max_slot_wal_keep_size, который автоматически удаляет неактивные слоты при достижении лимита.

gcloud sql instances patch your-instance-name \
  --database-flags=cloudsql.logical_decoding=on,max_slot_wal_keep_size=102400

Значение: 102400 = 100 ГБ (в мегабайтах)

Предупреждение: Если слот удален из-за превышения лимита, Debezium потеряет позицию и потребуется новый snapshot.

Cloud SQL vs Self-Managed PostgreSQL

Основное преимущество Cloud SQL: Автоматическое управление инфраструктурой, но с ограничениями в гибкости конфигурации.

Чеклист перед подключением Debezium Server

Перед переходом к следующему уроку убедитесь:

• Флаг cloudsql.logical_decoding=on включен и инстанс перезагружен
• SHOW wal_level; возвращает logical
• Создан пользователь debezium_user с REPLICATION привилегией
• Предоставлены права SELECT на целевые таблицы
• Создана publication для нужных таблиц
• Проверена publication через pg_publication_tables
• Настроен мониторинг pg_replication_slots (вручную или через Cloud Monitoring)
• (Опционально) Установлен max_slot_wal_keep_size для предотвращения WAL bloat

Что мы узнали

1. Cloud SQL специфика: Конфигурация через database flags вместо прямого редактирования postgresql.conf
2. cloudsql.logical_decoding flag: Аналог wal_level=logical для Cloud SQL
3. cloudsqlsuperuser role: Ограниченный superuser для управляемых баз данных
4. Replication user: Требует REPLICATION привилегию и SELECT на таблицы
5. Publication: Определяет таблицы для репликации, проверяется через pg_publication_tables
6. Мониторинг слотов: Критически важен для предотвращения WAL bloat и проблем с хранилищем

Что дальше?

В следующем уроке мы развернем Debezium Server с Pub/Sub sink — Kafka-less архитектуру CDC, которая публикует события напрямую в Google Cloud Pub/Sub, минуя Kafka Connect.

Bonus: AWS DMS vs Debezium на Aurora

Аналог Cloud SQL CDC в AWS экосистеме — Database Migration Service (DMS). Если вы делаете архитектурный выбор между managed CDC и self-hosted Debezium, эти отличия критичны.

Когда DMS, когда Debezium

AWS DMS (включая DMS Serverless с 2023):
  + Полностью managed: AWS провижит и масштабирует replication instance
  + Tight integration с Aurora, RDS, Redshift, S3, Kinesis
  + DMS Serverless: автоматическое scaling capacity по нагрузке
  + Time to production: часы
  - Только в AWS (lock-in)
  - SKIP tables без primary key в CDC mode (data gaps!)
  - Schema changes -- сложно: нет нативного DDL streaming
  - Дороже на устойчивой нагрузке: $0.40-1.20/hour replication instance

Debezium (self-hosted на MSK + Connect):
  + Cross-cloud: тот же стек на AWS, GCP, on-prem
  + Полный контроль над schema evolution и SMT chain
  + Эффективная цена на 10K+ events/sec
  + Поддерживает таблицы без PK (с tradeoff'ами)
  - Требует команду: 0.3-0.5 FTE platform engineer
  - Time to production: недели
  - Self-hosted Kafka cluster + Connect cluster

Schema replication strategy

DMS:
  Source schema -> CloudFormation/JSON mapping rules
  SchemaConversionTool (SCT) для cross-engine migrations
  DDL changes: некоторые автоматически, остальное -- ручная пересинхронизация
  Поведение: SKIP tables без PK при ongoing replication (важно для CDC!)

Debezium:
  Source schema -> Kafka schema (Avro / JSON Schema через Schema Registry)
  Schema changes streaming через DDL events на отдельный topic
  table.include.list / column.include.list -- fine-grained контроль
  Tables без PK: использует ROW IDENTITY FULL и full-row image как ключ

Cost models (10K events/sec, Aurora source)

DMS Serverless:
  ~10 DCU baseline, scaling to 30 DCU peak
  $0.20/DCU-hour -> $0.20 * 15 avg * 730 = ~$2 200/month
  + S3 storage если есть staging
  + cross-region transfer

Self-hosted Debezium на MSK:
  3-broker MSK kafka.m5.large = $1 200/month
  3 Connect workers m5.large = $600/month
  Schema Registry HA pair = $150/month
  Storage 7d retention ~ $480/month
  Total compute = ~$2 430/month
  + 0.4 FTE engineer ~ $5 000/month "true cost"

DMS выглядит дешевле на голом инфра-уровне для среднего workload, но переход на >50K events/sec обычно делает self-hosted экономичнее. Главное правило: для AWS-only стартапов с командой менее 10 человек — DMS; для multi-cloud / data-platform-team — Debezium.

Гибридные подходы

DMS для миграции (one-shot snapshot + первые недели CDC)
  -> переключение на Debezium когда команда выросла
  
Debezium для critical/high-throughput streams
  -> DMS для низкочастотных reference-таблиц
  
DMS на Aurora Postgres -> Kinesis -> Lambda
  Debezium на самописном MySQL -> MSK -> Flink

Aurora-specific gotcha: DMS без force-clean настройки оставляет slots в restart_lsn без heartbeat. То же самое, что мы решали через pg_logical_emit_message для Debezium — DMS делает это другим механизмом, но WAL-bloat закончится одинаково.