А информация о дата файлах и не нужна. Нужно понимать формат бекапа, а это pg_probackup3 умеет. Восстановление, как и при других физических видах бекапа, возможно только на ту же мажорную версию Postgres на той же архитектуре.
Да, посыпаем голову пеплом - pgbackrest научили в S3 в 2019, а мы забыли обновить табличку. Плюсик вам за внимательность.
Но, как обычно, есть нюанс. Задача прилепить поддержку S3 уже давно ушла на уровень церковно-приходской школы и двух запросов в чатгпт. Весь вопрос в том, чтобы уметь готовить файлы в удобном для s3 формате. Так что просто сдампить pgdata и залить на блочный сторадж это ну так себе достижение.
Строго говоря да, в pg_dump действительно нет возможности сохранения в S3, но есть скрипт в полторы команды, который и так все используют. Скопировать 1 текстовый файл, не сложно, поэтому при составлении таблицы мы решили ему немножко подыграть https://devcoops.com/pg_dump-to-s3-directly/
Да, есть такое. Но на Майкрософт мы повлиять не можем. С другой стороны, все понимают что рано или поздно в ванилле тип данных тоже изменится, после чего им придется изменить свой драйвер.
P.s. в standart версии ксиды хранятся по старорежимному, так что если нет потребности именно в ent, это не будет проблемой.
Это неточность формулировки. Правильно должно звучать так: надо было бы писать не 8, а 16 (в статье исправил тоже). Именно по этой причине мы не пошли таким путём. Мы храним туплы в старом 32–х битном формате, сохраняя 8 байт ксидов для каждого тупла, но дополнительно размещаем на странице “базу”, сложение с которой и выдаёт нам 8-ми байтный ксид.
Люди ответственные за разработку баз данных, обычно, хорошо понимают в базах данных, но не в том как их обслуживать на местах. С этого попался и началась: нативных внятных тулов для такой простой операции как бекап - нет.
Супер, спасибо. Насколько я знаю PM'ы ишуи регулярно смотрят и самое интересное берётся в разработку. В ent версии действительно что-то уже сделано, но, как я говорил выше, надо дождаться выхода тройки, потому что основные усилия разработчиков сейчас там.
Задача была не протащить всех кто пришёл в ближайший коммитфест, а обсудить патчи, решаемые проблемы и, самое главное, найти ревьюеров. С этой частью справились, а приведёт-ли это к результату в виде мёржа в ближайшем коммитфесте - посмотрим. Но процесс принятия патчей в постгресе никогда быстрым не был.
И не напишут таких статей. Нельзя раскрывать детали кии.
Так перестали распространять или можно использовать?
Хорошо что удалось раскрыть очередной заговор. Виноватые будут награждены, а невиновные наказаны =)
Не читайте советских газет по утрам, когда можно сразу обратиться к первоисточнику: https://postgrespro.ru/education/books/internals
Кажется на книге написана другая фамилия в графе автор.
Всё же это статья о функциях pg_probackup3, а не попытка сравнить его со всеми другими инструментами, коих достаточно много.
pg_probackup2 использует наработки pg_arman и об этом честно написано на Github https://github.com/postgrespro/pg_probackup/tree/master так что тут никакой великой тайны.
А информация о дата файлах и не нужна. Нужно понимать формат бекапа, а это pg_probackup3 умеет. Восстановление, как и при других физических видах бекапа, возможно только на ту же мажорную версию Postgres на той же архитектуре.
Да, посыпаем голову пеплом - pgbackrest научили в S3 в 2019, а мы забыли обновить табличку. Плюсик вам за внимательность.
Но, как обычно, есть нюанс. Задача прилепить поддержку S3 уже давно ушла на уровень церковно-приходской школы и двух запросов в чатгпт. Весь вопрос в том, чтобы уметь готовить файлы в удобном для s3 формате. Так что просто сдампить pgdata и залить на блочный сторадж это ну так себе достижение.
Строго говоря да, в pg_dump действительно нет возможности сохранения в S3, но есть скрипт в полторы команды, который и так все используют. Скопировать 1 текстовый файл, не сложно, поэтому при составлении таблицы мы решили ему немножко подыграть
https://devcoops.com/pg_dump-to-s3-directly/
Это всё хорошо, но вы объясните удивленной публике, почему в Яндексе зумом пользуются, а не прекрасным телемостом?
Вот бы об этом были первые же два абзаца...
Да, есть такое. Но на Майкрософт мы повлиять не можем. С другой стороны, все понимают что рано или поздно в ванилле тип данных тоже изменится, после чего им придется изменить свой драйвер.
P.s. в standart версии ксиды хранятся по старорежимному, так что если нет потребности именно в ent, это не будет проблемой.
Это неточность формулировки. Правильно должно звучать так: надо было бы писать не 8, а 16 (в статье исправил тоже). Именно по этой причине мы не пошли таким путём. Мы храним туплы в старом 32–х битном формате, сохраняя 8 байт ксидов для каждого тупла, но дополнительно размещаем на странице “базу”, сложение с которой и выдаёт нам 8-ми байтный ксид.
Люди ответственные за разработку баз данных, обычно, хорошо понимают в базах данных, но не в том как их обслуживать на местах. С этого попался и началась: нативных внятных тулов для такой простой операции как бекап - нет.
Супер, спасибо. Насколько я знаю PM'ы ишуи регулярно смотрят и самое интересное берётся в разработку. В ent версии действительно что-то уже сделано, но, как я говорил выше, надо дождаться выхода тройки, потому что основные усилия разработчиков сейчас там.
Но вы так уверенно говорите, что публичная версия пробекапа безнадёжно отстала и там никакого развития, будто у вас есть список того чем обделили.
А чего конкретно не хватает в публичной, из того что есть в закрытой?
Это станет известно ближе к релизу, потому что вот так звёзды складываются, что прямо сейчас никто вам на этот вопрос точно не ответит.
Вы можете привести пример IT конференций, где всем спикерам платят?
Смешно. Конечно нет.
Задача была не протащить всех кто пришёл в ближайший коммитфест, а обсудить патчи, решаемые проблемы и, самое главное, найти ревьюеров. С этой частью справились, а приведёт-ли это к результату в виде мёржа в ближайшем коммитфесте - посмотрим. Но процесс принятия патчей в постгресе никогда быстрым не был.