Мне действительно интересно мнение Ильи. Вот почему встроенный движок резервного

копирования, который не создаёт блокировок и не тормозит выполнение запросов, хуже, чем сторонний инструмент, который блокирует базу?

Блокирует ли система резервного копирования базу -- зависит не от того, встроенная она или внешняя. Искренне Ваш, КО.

Кстати, никогда не настраивал правильный бэкап MS SQL (вообще мало работал, там где нужно было -- херачил весь вольюм с базой и другими данными приложэния через снимки shadow copy, всё восстанавливалось). Где там про неё почитать можно, на будущее?

А от чего зависит?

Или официальная документация МС, или их модуль по подготовке к сертификации ДБА

Ты бы лучшэ или название этого раздела документацыи сказал, или ссылку кинул. А то просто поиском мс-док можно на такую чухню попасть...

От реализацыи. И да, я вообще не помню ни одного блокирующего инструмента бэкапов под postgres.

Как бы все известные мне инструменты бекапов в ПГ накладывают те или иные блокировки блокируя транзакции

Какбы это не так. Я бы хотел use case, когда это действительно правда. Что они блокируют -- так это всякий вакуум/автовакуум. И то, не в смысле что он не идёт, а в смысле -- что то, что ещё должно быть сбэкаплено пока не удаляется.

https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/quickstart-backup-restore-database?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/t-sql/statements/backup-transact-sql?view=sql-server-ver15

Спасибо.

И да, движок резервного копирования не можэт не тормозить выполнение запросов -- потому, что ему нужно выполняить работу, и он использует ровно те жэ ресурсы, что и основной сервер. (А насколько он тормозит -- это ужэ впрос для обсуждения).

Если аппаратных ресурсов с избытком - упираемся в реализацию. Можно назвать какой именно из способов резервного копирования в ПГ не лочит объекты?

И да, для бэкапа в postgres есть два встроенных варианта -- pg_dumpall, который таки дамп и многие его не считают бэкапом. Но он тожэ ничего не блокирует, кроме разве что возможно изменений каталога. Логическая выгрузка данных сервера. И pg_basebackup -- делает копию файлов сервера и сохраняет лог со всем, что изменилось пока он это делал. Этот вообще ничего не блокирует, кроме удаления старых логов. Работает, кстати, поверх протокола репликацыи (ну, поднимает такую реплику, фактически). И несколько систем резервного копирования -- barman, wal-g, pg_probackup, ещё кто-то -- которые тожэ все работают на физическом уровне, примрено как pg_basebackup -- зато имеют расписание бэкапов, расписание удалений, кое-кто -- хранение журналов PITR и восстановление отдельных баз из сервера.

pg_dumpall накладывает shared-блокировки на таблицы, которые выгружает. Т.е. все операции, которые требуют эксклюзивных блокировок (update, delete, insert) будут ждать. У него даже ключ есть lock-wait-timeout, чтобы обрывать процесс резервного копирования, если не удалось блокировку наложить. pg_basebackup использует механизм репликации и, по сути, побитово копирует базы и делает бекап WAL на момент создания бекапа. Тут я обосрался, каюсь. Но так пишет официальная документация, я пока копаю, потому что из личного опыта - тормоза есть. И! Он бекапит ВСЕ базы! Без возможности выбора. И для рестора нужно стопить СУБД. Это в 2021 году. Хоть убейте, нет нормального бекапа и рестора в ПГ, нет

>.е. все операции, которые требуют эксклюзивных блокировок (update, delete, insert) будут ждать. Нет. Там ACCESS SHARE lock , он конфликтует только или с прямым LOCK table IN ACCESS EXCLUSIVE или с DDL (alter table и TRUNCATE всякими). (Впрочем, не советую начинать бэкапы с pg_dump -- там есть проблемы. Они все решаемые, в том числе post-factum -- текст SQL всё-таки практически -- но проблем с триггерами и check constraints хватает.) >! Он бекапит ВСЕ базы! Без возможности выбора. На самом деле, по внутренней кухне -- базы в MS SQL Server ближэ к разным инстансам (ака "кластерам", дурацкое название, да) постгреса. Разный transaction log, например. Так что в MS SQL Server тожэ не так просто сбэкапить часть базы данных или восстановить её без остановки.

По поводу последнего, так это в любой базе не имеет смысла, так как нет гарантии консистентности данных... А вот одну базу бекапить и восстановить в ПГ хотелось бы

Я вообще не понял этой твоей реплики. Что не имеет смысла? Бэкапить часть базы данных? Я не соглашусь. Смысл имеет. Я иногда дажэ использую (pg_dump или mysqldump или дажэ exp в своё время, выделенные таблицы, да). Редко, да, поскольку у этих утилит есть проблемы -- и вообще нужно нечасто. Но тяжко, да.

влезу в разговор, не видя всей картины.. к примеру mariadb, если со слейва делать дамп базы/таблицы, ведь проблем не должно быть или есть?

Это если есть понимание, что происходит с базой. В МС тоже можно заскриптовать всю таблицу, или сделать копию и потом восстановить. Но это на совести ДБА. Где гарантия, что потом не было транзакций, которые ссылаются на данные, которые были вставлены после такого бекапа? К примеру, есть клиенты и их заказы. База большая и высоконагруженная, поэтому от внешних ключей отказались. Делаем копию таблицы клиентов перед изменением структуры. Изменение структуры прошло криво, удаляем таблицу и пепеименовываем копию. Но за это время добавилось пару клиентов и они сделали пару заказов. Будут заказы-сироты. Пример очень примитивный. На базах с большим количеством таблиц с взаимосвязями такие вещи сложно отследить. Я об этом

Я ХЗ, если честно. Ну, то есть у меня нет сложных баз mysql -- потому я просто не знаю, решыли ли в mysqldump все проблемы с referential integrity/checks/triggers. С другой стороны, проблема, которой часто пинают pg_dump -- это малопредсказуемое время восстановления. И это в mysqldump тожэ присутствует, конечно.

Я опять не понял, что ты хочешь сказать. Ну и ладно.

со временем восстановления - полностью согласен, а вот там читал про проблемы выше и сомневаюсь что они есть, тем более, если их делать из слейвов(дампы).

Я про консистентность базы на момент времени. Восстановление объектов её не даёт, только восстановление базы полностью