при смене версий, хотя и не гарантировано
я все еще жду кейс когда такое восстановление запоролось и по какой причине
на моей практике - никогда, хотя я с такими видами бекапов и не часто сталкивался, все же
и не слышал ни от кого
Есть один вариант, когда автоматически дамп не развернётся: при нарушении целостности из-за неправильного порядка вставки записей. Проще всего подстроить если внешний ключ вешается на исходную таблицу (для хранения дерева или графа). Но в этом случае есть возможность ручками поправить порядок команд, хотя это будет тот ещё ад.
То, что Вы чего-то не видели в своей практике, означает, что этого не существует? ;) Вот посмотрите. Ну и вообще, недостатки дампов на этом не заканчиваются (и документация лжёт даёт неправильную информацию о его свойствах), но с ними, к счастью, ещё реже сталкиваются на практике. А столкнувшись — переходят на другую работу другую СУБД нормальное решение. ;)
а есть патч на эту документацию полайкать на коммитфесте?
это называется подводные камни, к томуж е довольно редкие, и вот поэтому хотелось бы обсуждать причины таких отказов в ресторах, а не собственно просто заявления о том, что они случаются.
Причина проста: можно сделать циклические ссылки в записях, так что А ссылается на Б, а Б ссылается на А и в лоб такое не вставишь. Такое можно разрулить только отложенной проверкой ключей (чего нет, если я правильно помню) либо костылями (вставить А с null, вставить Б, поменять в А null на ссылку на Б).
это зависит от того, как добавляются ограничения, до заливки данных или после логично сначала залить данные, а потом добавить или активировать внешние ключи я не знаю как именно утсроен внутри пгдамп, но он по идее обязан такое учитывать, иначе графы им вообще не залить никакие
Нет. Я не уверен, что могу грамотно писать нетривиальные изменения в английскую документацию. А так-то про дюжины [дюжин] ошибок я в -hackers (или -docs, не помню) сообщал... и большая их часть всё ещё с нами, насколько я помню. ;(
Не один. И есть ещё варианты, когда консистентный дамп не снимется. И [некоторые/многие] hackers о них, естественно, знают, но... worse is better (и вообще, возвращаясь к началу темы: "dump is not backup, didn't you know?!" и "well, who cares what's written in documentation?!" ;) ).
А мой посыл в "против дампов" состоит вовсе не в этих "камнях", то-то и оно. А в том, что реалистичные RPO/RTO с ними обеспечить в нетривиальных случаях нереально — и других причин не пользоваться ими уже не нужно.
ну как архивы-то хоть можно? по прямому назначению
По-моему, Вы так и не ответили, что такое "архивы" в принципе (потому что в документации слово же используется, а не определяется... или нет)?
Обсуждают сегодня