Зачем это знать? Потому что 95% ручных скриптов на миграции - это типичная архитектурная грабля. pglogical берёт на себя репликацию таблиц, и старые костыли уходят в /dev/null. Проблемы с DDL, WAL и лагами решаются нативно, без лишнего кода.

Что под капотом у pglogical и почему он рвёт легаси

pglogical - это расширение для логической репликации в PostgreSQL. Не физические байты WAL копирует, а SQL-команды: INSERT, UPDATE, DELETE. Мастер шлёт изменения на реплику по подписке, без привязки к диску или архитектуре. Идеально для миграции между версиями - от 9.4 до свежей 18-й.

Под капотом: декодирование WAL в логические изменения. Нужен wal_level = logical, плюс настройка слотов репликации. Легаси-миграции обычно ковыряют дампы или триггеры - медленно, с downtime. pglogical стримит в реал-тайм, но DDL не всегда реплицируется - вот где новички тонут. Пример: добавляешь колонку на мастере, реплика не видит, cron пытается подправить - и привет, рассинхрон.

• Слот репликации: SELECT * FROM pg_replication_slots; - проверяй, не раздулся ли. Если лаг > 1GB, мастер задохнётся.
• Подписки: pglogical.replication_set_add_all_tables - реплицируй выборочно, не всё сразу.
• Нюанс: pglogical не любит TOASTed поля - сжимай их заранее, иначе трафик взлетит.

Три cron-джоба, которые pglogical угробил - разбор полётов

Первый джоб синхронил изменения по триггерам. Каждый UPDATE на мастере фейрил на реплике, cron ковырял diff по primary key. pglogical взял репликацию на себя - джоб в корзину. Но внимание: если таблица без PK, репликация сломается - pkless tables не поддерживаются.

Второй - бэкап/восстановление по расписанию. Легаси-скрипт дампил delta, заливал на slave. С pglogical дельта стримится continuously, cron просто проверял лаг: pg_wal_lsn_diff(sent_lsn, replay_lsn). Если >0 - алерт, но сам джоб мёртв. Пример из продакшена: 500GB база мигрировали за ночь, лаг не превысил 10MB.

Третий - ротация логов и vacuum. Cron чистил orphaned записи, подгонял под реплику. pglogical с origin-фильтрами и subtxn handling это покрывает нативно. Остался только мониторинг: SELECT * FROM pg_stat_replication. Минус: full_page_writes off временно, ionice/renice для приоритетов.

1. Триггерный sync: убирай все триггеры перед подпиской - ALTER TABLE DROP TRIGGER.
2. Delta дампы: замени на pglogical.show_subscription_status.
3. Vacuum cron: полагайся на autovacuum реплики, мониторь pg_stat_user_tables.

Грабли миграции: от WAL до переключения трафика

Настройка pglogical начинается с CREATE EXTENSION pglogical. На мастере - node creation, на реплике - subscription. Ключ: реплицируй schema сначала вручную, DDL не всегда прокатывает. Пример: ALTER TABLE на мастере - реплика в стагнации, ручной sync через pglogical.sync().

Лаги? Увеличивай wal_keep_segments, отключай fsync temporarily. Переключение: stop writes на мастере, sync реплику, flip DNS/app config. Время - минуты, если стек простой. Сложный стек (proxy, connection pool) - тестируй blue-green заранее.

• wal_level=logical: обязательный, иначе слоты не стартуют.
• max_replication_slots=10: не жадничай, слоты жрут RAM.
• Грабль: pglogical < PG12 имеет баги с subtransactions - апгрейдь до 3.x.

Репликация убила джобы - что на выходе

Итог: 95% легаси-миграций в /dev/null, три cron-а мертвы, база мигрирована zero-downtime. Осталось чистить слоты репликации и мониторить byte_lag - больше ничего не мешает.

Под капотом pglogical раскрывает нативную мощь PostgreSQL. Дальше думай о multi-master или шardinгe - но это уже без костылей.