Настройка 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.