Достаточно часто во время обучения корпоративных заказчиков особенностям эксплуатации PostgreSQL сталкиваюсь с одними и теми же заблуждениями...
Ну что ж, буду понемногу опрозрачивать эту тему.
Заблуждение № 1:
Резервная копия PostgreSQL будет настоящей только если выгнать всех пользователей из базы 1С и заблокировать базу.
Заблуждение № 2:
Резервное копирование PostgreSQL это только Dump.
Заблуждение № 3:
Резервное копирование PostgreSQL это только весь сервер с помощью basebackup, а базу отдельно забэкапить невозможно.
Заблуждение № 4:
Резервная копия PostgreSQL не имеет обратной совместимости, т.е. копия сделанная на версии 14 не сможет быть восстановлена на версии 15 и новее (сейчас есть уже 18).
Заблуждение № 5:
Резервная копия PostgreSQL может быть только полной и не умеет делать дифференциальные или инкрементные копии.
Как обстоят дела на самом деле:
Резервная копия (бэкап) субд PostgreSQL является что ни на есть настоящей и консистентной даже если сделана во время работы базы и не требует ни отсутствия пользователей в 1С ни блокировки базы.
В отличии от MS SQL где есть только один вид резервного копирования, PostgreSQL имеет два основных вида:
▫️PG_Dump
▫️PG_BaseBackup
В чём их особенности:
PG_Dump - это логическое чтение всех данных со всех таблиц базы данных.
В следствии этого копия созданная утилитой pg_dump консистентна на начало копирования (в отличии от MS SQL, резервная копия которого консистентна на момент окончания копирования).
Так же pg_dump поскольку является по факту просто запросом select с выводом в файл имеет много гибких настроек.
Можно исключить определенные таблицы из копии (очень полезно при создании копии для среды разработки и тестирования, например можно выкинуть иэ бэкапа таблицу истории данных или версионирования данных)
Так же dump не содержит индексов, а содержит только команды их создания. Из-за этого бэкап сделанный с помощью dump занимает намного меньше места чем копия созданная на СУБД MS SQL, которая как раз таки содержит и индексы.
Копия созданная утилитой pg_dump имеет обратную совместимость, т.е. нет никаких проблем в том чтобы создать копию на версии 14 и восстановить её на версии 17.
Единственный нюанс состоит в том, что использовать утилиту восстановления pg_restore нужно в этом случае именно версии 17.
Это ещё не всё про pg_dump)))
Формат резервной копии этой утилиты может быть трёх видов:
▫️-Fp - plain
▫️-Fc - custom
▫️-Fd - directory
Plain - просто текстовый формат, выходной файл будет состоять из команд insert.
Особенность в том что этот формат однопоточный, НО можно немного схитрить и отправить результат команды не в файл, а в поток, а этот поток уже многопоточно сжать через pigz для windows или любого аналога для Linux и тем самым кратно ускорить создание резервной копии
| c:\util\pigz\pigz.exe -p4Плюсы - квазимногопоточность создания бэкапа
Минусы - восстановление только в один поток и предварительно необходимо распаковать файл резервной копии
Custom - это встроенный формат бэкапа, сжимается на лету
Плюсы - многопоточное восстановление. Не требует предварительной распаковки
Минусы - однопоточное создание бэкапа
Directory - бэкап на уровне каталога.
Особенность - гарантированно выполняется только на заблокированной базе, если же базу не блокировать, то возможно что система затребует блокировку таблицы, которую ещё не забэкапили и тогда pg_dump прервёт свою работу по ошибке.
Плюсы - многопоточное создание и восстановление. Не требует предварительной распаковки
Минусы - гарантированное выполнение только на заблокированной базе.
Особенности любых резервных копий, создаваемых через pg_dump:
Только полное резервное копирование, никаких дифференциальных и инкрементальных копий.
После восстановления из резервной копии необходимо выполнить операцию обновления статистики, благо в PostgreSQL она очень быстрая.
Проверки на валидность файла резервной копии не существует, контролировать нужно именно отсутствие ошибок при работе pg_dump.
Про особенности, плюсы и минусы pg_basebackup расскажу в следующий раз.