Дамп 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
