13 зависит от объема данных в базе? Мне казалось что там используются hard links и время обновления не должно сильно зависеть от объема данных
через pg_upgrade если, то да, hard links. время зависит от сложности схемы (pg_dump+pg_restore schema-only) + время сбора статистики (но это уже на запущенной базе). обычно в 10-20 минут можно уложиться
У pg_upgrade есть --link, да. Только что толку, если все равно прочитать все надо.
хм, что прочитать? только системный каталог, всё остальное линкуется. у меня еженедльные тесты на 10TB базе с 2-мя табличными областями — 31 минута в среднем на апгрейд со сбором полной статы.
Интересно. Тогда я вообще плохо понимаю, зачем pg_upgrade нужен.
в смысле? это он и делает всё. без него имеем либо pg_dump+pg_restore с непонятным, но где-то в районе суток даунтаймом. либо через логическую репликацию, с плясками по переносу схему и синхронизации всего, кроме таблиц.
А что он такого делает, чего нельзя воткнуть в код постгреса, чтобы он, обнаружив старую версию под собой, молча жевал свой системный каталог? Recovery же мы тоже не вручную запускаем, и никто не умирает от этого.
pg_upgrade — системная утилита, которая: - делает проверку совместимости инсталляций - переносит системный каталог - линкует файлы - правит контольные файлы. в код постгреса это не втыкают чтобы не сложнять его, т.к. пришлось бы слишком много ветвлений для разных версий иметь. т.к. перезапуск всё равно нужен, делаем всю работу через утилиту
Ну хорошо. Не в код. Но пусть он этот pg_upgrade сам вызывает и сам себя перезапускает. Какого черта я, средняя скриптомакака, которая ничего сложнее инстанса за $10 на AWS в жизни не видела, должна пользоваться отдельной утилитой, у которой 10 опций командной строки, позволяющих по-разному отстрелить себе ноги?
Ради того, что происходит раз в год, делать нетривиальный анализ каждый раз при... старте/первом обращении к таблице? А если что-то пойдёт не так? Апгрейд - всё-таки планируемая операция, а тут нежданчик може прилететь после каждого рестарта СУБД. Например, флипнулся бит где-нибудь в заголовке таблицы - просто она не будет читаться. А если встроить апгрейд, то можно вообще попортить все данные из-за ложного детекта.
xlog мы переименуем в wal, чтобы неподготовленные пользовали перестали удалять «какие-то логи», а у остальных все скрипты сломались.
Обсуждают сегодня