Все условия необходимые для воспроизведения бага подробно описаны.
Исходники софта для проверки тоже.
Очевидно что сидеть и проверять каждую версию ядра, в каждом дистрибутиве мы не можем т.к. это займёт околобесконечное количество времени. Проведите эксперимент на доступных вам системах, поделитесь результатами и все скажут вам спасибо.
На больших размерах БД очень даже не избыточна, а весьма полезна. Большие файлы индексов, wal файлы и сами таблицы скажут вам спасибо. Особенно при частых UPDATE/DELETE.
Следом идут блоки до 64 КБ, чтобы удобно работать с восьмикилобайтными страницами постгреса. И не забываем про многопоточку и раздельную работу с журналами метаданных.
А информация о дата файлах и не нужна. Нужно понимать формат бекапа, а это 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 версии действительно что-то уже сделано, но, как я говорил выше, надо дождаться выхода тройки, потому что основные усилия разработчиков сейчас там.
Все условия необходимые для воспроизведения бага подробно описаны.
Исходники софта для проверки тоже.
Очевидно что сидеть и проверять каждую версию ядра, в каждом дистрибутиве мы не можем т.к. это займёт околобесконечное количество времени. Проведите эксперимент на доступных вам системах, поделитесь результатами и все скажут вам спасибо.
На больших размерах БД очень даже не избыточна, а весьма полезна. Большие файлы индексов, wal файлы и сами таблицы скажут вам спасибо. Особенно при частых UPDATE/DELETE.
Следом идут блоки до 64 КБ, чтобы удобно работать с восьмикилобайтными страницами постгреса. И не забываем про многопоточку и раздельную работу с журналами метаданных.
Так что XFS это дефолтная опция в энтерпрайзах.
Я пока не знаю где бы офисы бесплатно раздавали. Дайте знать, если найдёте.
И не напишут таких статей. Нельзя раскрывать детали кии.
Так перестали распространять или можно использовать?
Хорошо что удалось раскрыть очередной заговор. Виноватые будут награждены, а невиновные наказаны =)
Не читайте советских газет по утрам, когда можно сразу обратиться к первоисточнику: 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 версии действительно что-то уже сделано, но, как я говорил выше, надо дождаться выхода тройки, потому что основные усилия разработчиков сейчас там.
Но вы так уверенно говорите, что публичная версия пробекапа безнадёжно отстала и там никакого развития, будто у вас есть список того чем обделили.
А чего конкретно не хватает в публичной, из того что есть в закрытой?
Это станет известно ближе к релизу, потому что вот так звёзды складываются, что прямо сейчас никто вам на этот вопрос точно не ответит.