Comments 9
Спасибо, познавательно и очень своевременно!
По сути, вы разворачиваете специализированную реплику для вашей базы. И на одной машинке вы можете держать сразу 20-30 клонов. И каждый клон полноразмерный и независимый. Можно гонять все ALTER, СREATE INDEX в своей базе. Это может делать разработчик, тестировщик. Можно развернуть такой полноразмерный клон чисто для тестирования, т. е. у вас появляются полноразмерные среды, разворачиваемые за 10 секунд. У вас 10 терабайт база, а клон разворачивается за 10 секунд.
Мы создали клон, а в основной БД за пару часов наапдейтилось на 100гб, куда пишется дельта? А если 30 клонов?
Или все таки мы разворачиваем статичный бэкап часов за 20, а потом уже с него за 10 секунд делаем клоны?
Автор не я. Поэтому спросите в чате https://t.me/databaselabru
В докладе рассказывалось про вариант "DLE как 'многоголовая реплика'" — это возможно только в случае, если PGDATA получена в physical mode, и используется физическая репликация. Например, получение WAL-ов по restore_command из архива. Можно и напрямую с прода, но обычно рекомендуем не трогать прод.
В logical mode пока такое не работает (а могло бы, надо только поддержку логической репликации добавить; при этом, конечно, придётся подключаться к мастеру для этого — это ограничение Postgres, ни из архива, ни даже с реплик logical decoding пока не умеет работать).
>Куда пишется?
В таком варианте запущен так называемый sync-контейнер, он получает WAL-ы и пишет их в "основную" PGDATA. Вот здесь это конфигурится: https://postgres.ai/docs/reference-guides/database-lab-engine-configuration-reference#job-physicalrestore. Это по сути тоже Postgres, единственная задача которого — получить и накатить WAL-ы. При нагрузках стоит поднять ему shared_buffers, чтобы не отставал. А вот тут https://postgres.ai/docs/reference-guides/database-lab-engine-configuration-reference#job-physicalsnapshot задаётся логика создания снапшотов — например, каждый час делаем новый, а также держим последних 48 (2 дня). Такие снапшоты уже и используются для клонирования. При клонировании по умолчанию используется самый свежий снапшот. В схеме "снапшот раз в час", значит, данные будут не старее, чем час. Но юзер может и выбрать, на основе какого снапшота из списка делать клон.
При этом, конечно, можно и статично развернуть и иметь только 1 снапшот.
С logical mode всё иначе — там всегда 1 снапшот у ZFS pool, но можно держать несколько пулов и настроить логику ротации https://postgres.ai/docs/reference-guides/database-lab-engine-configuration-reference#section-poolmanager-filesystem-pools-or-volume-groups-management, т.е. только получение "PGDATA целиком" по расписанию, но несколько дисков и несколько полноценных (толстых) копий PGDATA, на основе которых можно клонировать.
zfs send/receive пока никак не используется — предполагается, что в проде ZFS нет.
DO-UNDO-DO
делать, но не на проде!?
извините, а зачем?
какой из поставленных вопросов решает undo?:
база плохая, и поэтому, деплой не идет, или идет медленно, или застревает
деплой прошел, но все стало хуже - индекс, не то, что надо индекс
Казалось-бы: 2-й, но, а если там, например, таблица/колонка, которая требуется новой версии аппликухе, которую задеплоили после деплоя базы? Откат (UNDO) деплоя базы на проде, который мы протестировали, и наконец-то можем использовать; и DBA с радостью это исполнит, но вот все остальным станет плохо (апликуха перестанет работать медленно - она просто сломается)! Так-же в таблицах/колонках, уже могут появиться данные, которые UNDO удалит. Отмена деплоя может выполняться в ручном режиме - есть шанс ошибиться с версией (точку не там поставили) и поудалять таблицы с данными.
В самом начале статьи: Опасное дело - деплой, да еще и под нагрузкой, а вы рекомендуя UNDO, делаете процесс более рискованным.
Делайте новый скрипт, прогоняйте на пре-прод(ах) и деплойте - по времени, может быть даже быстрее, чем UNDO.
И конечно не решается вопрос отсутствия согласованности схем базы на разных уровнях. Если таблица уже есть, то деплой не пройдет, и нечего UNDO. Если деплой идет медленно - с его прервали, тоже нечего будет отменять. То есть IF NOT EXISTS и UNDO, вообще перпендикулярны.
Имхо - решатся причина проблемы двумя путями:
организационная: почему появилась не учтенная таблица?
техническая: dump - resotre - obfuscate - propagete, т.е. получить копию близкую к проду, плюс организовать стресс тест, и протестировать деплой базы и сравнить статистику. Вплоть до дев и локальных баз, после удаления до приемлемых размеров.
В статье предлагается делать DO-UNDO-DO в CI на тестовой базе (копия прода, сэмпл, фикстура, даже пустая база). Такой подход нужен для того, чтобы тестировать не только DO/deploy, но и UNDO/revert. Использование UNDO в проде не рекомендуется, но для дев сред наличие корректно работающих UNDO/revert может быть полезно.
... UNDO/revert может быть полезно.
Очень-очень сомнительная полезность, которая, конечно позволяет не делать restore, но не решает кучу других проблем, а добавляет И сложности, И рисков.
Короче типичный анти-паттерн, при этом:
DO-restore(pre-prod)-DO(prod), позволяет И сложность скриптов уменьшить (не надо писать лишнее), И риски убрать (drop-ы), И тест backup-restore сделать, И скрипты проверить в близкой к prod ситуации (добавив стресс тест нагрузку).
В продолжение разговора о lock_timeout и retries - https://postgres.ai/blog/20210923-zero-downtime-postgres-schema-migrations-lock-timeout-and-retries
Распространённые ошибки изменения схемы базы данных PostgreSQL (Николай Самохвалов)