fix(ops): восстановление не падает в хвосте из-за незаведённых ролей #3089

Merged

lekss361 merged 1 commit from fix/3057-restore-globals into main

2026-08-25 05:18:54 +00:00

lekss361 commented

2026-08-25 05:18:30 +00:00

Owner

Summary

ops/restore.sh не загружал globals, хотя дамп ссылается на роли кластера в OWNER TO и GRANT, а psql идёт с ON_ERROR_STOP=1.
На кластере без ролей восстановление обрывалось на первом таком операторе — уже ПОСЛЕ заливки данных (в одну транзакцию psql дамп не оборачивает). Это ровно путь переезда: на новом хосте кластер пустой.
Соседний <проект>_globals_<метка>.sql.gz теперь подхватывается автоматически и грузится первым — как это давно делает ops/restore-drill.sh; разошлись только два скрипта.
Побочный эффект (globals возвращает пароли ролей на момент дампа) назван в шапке; рычаги — RESTORE_SKIP_GLOBALS=1 и RESTORE_GLOBALS_FILE=....

Test plan

bash -n
ветка автоопределения прогнана на паре файлов с реальными именами — сосед находится
смежная проверка на живом хосте: восстановление 15 ГБ с globals прошло за 5 мин 32 с, 0 ошибок, роли auth_app / forgejo / gendesign / glitchtip / tradein_fdw_reader на месте
в окне переезда — этот же путь на боевом восстановлении

Refs #3057

## Summary - `ops/restore.sh` не загружал globals, хотя дамп ссылается на роли кластера в `OWNER TO` и `GRANT`, а psql идёт с `ON_ERROR_STOP=1`. - На кластере без ролей восстановление обрывалось на первом таком операторе — уже ПОСЛЕ заливки данных (в одну транзакцию psql дамп не оборачивает). Это ровно путь переезда: на новом хосте кластер пустой. - Соседний `<проект>_globals_<метка>.sql.gz` теперь подхватывается автоматически и грузится первым — как это давно делает `ops/restore-drill.sh`; разошлись только два скрипта. - Побочный эффект (globals возвращает пароли ролей на момент дампа) назван в шапке; рычаги — `RESTORE_SKIP_GLOBALS=1` и `RESTORE_GLOBALS_FILE=...`. ## Test plan - [x] `bash -n` - [x] ветка автоопределения прогнана на паре файлов с реальными именами — сосед находится - [x] смежная проверка на живом хосте: восстановление 15 ГБ с globals прошло за 5 мин 32 с, 0 ошибок, роли `auth_app / forgejo / gendesign / glitchtip / tradein_fdw_reader` на месте - [ ] в окне переезда — этот же путь на боевом восстановлении Refs #3057

lekss361 added 1 commit 2026-08-25 05:18:30 +00:00

fix(ops): восстановление не падает в хвосте из-за незаведённых ролей

CI Trade-In / changes (pull_request) Successful in 9s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / changes (pull_request) Successful in 11s

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

8a5d323608

Дамп backup.sh — это одна база, а роли живут в кластере и уезжают соседним
файлом gendesign_globals_<ts>.sql.gz. Сам дамп на эти роли ссылается: OWNER TO
и GRANT. psql здесь идёт с ON_ERROR_STOP=1, поэтому на кластере, где ролей ещё
нет, восстановление обрывается на первом же таком операторе — но данные к тому
моменту уже залиты и закоммичены, в одну транзакцию psql дамп не оборачивает.
Итог: наполовину собранная база и невнятная ошибка в самом конце, после всей
работы.

Ровно этот путь и нужен при переезде: на новом хосте кластер пустой, ролей нет.

Теперь соседний globals подхватывается автоматически и грузится первым — так
уже давно устроен ops/restore-drill.sh, разошлись только эти два скрипта.
Правило имени взято оттуда же.

Побочный эффект назван в шапке прямо: globals несёт пароли ролей на момент
снятия дампа, и если пароль меняли после, он вернётся к старому. Для поднятия
кластера с нуля это правильное поведение, для точечного отката данных в живой
базе — нет, поэтому есть RESTORE_SKIP_GLOBALS=1 и RESTORE_GLOBALS_FILE.

Сам globals грузится БЕЗ ON_ERROR_STOP: на живом кластере роли уже есть и
CREATE ROLE для каждой законно падает с already exists. Значимая часть — идущие
следом ALTER ROLE, они отрабатывают.

Если соседа нет и он не отключён явно — печатаем предупреждение ДО заливки,
чтобы «упадёт через час» не стало сюрпризом. Не падаем: на живом кластере роли
на месте и всё пройдёт как раньше.

Проверено: bash -n; ветка автоопределения прогнана на паре файлов с реальными
именами — сосед находится. Поведение на живом кластере не меняется: globals
идёт первым, дальше всё как было.

Refs #3057