Спасибо за статью. Не увидел в ней или пропустил хоть что-то про техническую поддержку вендора уровня enterprise с выездом инженера на место установки для замены вдруг вышедших из строя блоков (а это вообще поддерживается?). Без такого рода поддержки, какая бы железка не была живучей и отказоустойчивой, но практика показывает, что ломается даже то, что казалось бы не может ломаться.
Жаль, что в статье нет ничего про проект шардированного Postgres SPQR от Yandex
Проект довольно зрелый в отличии от Multigres
Ну и про то что Postgres никогда не поднимался выше MySQL в рейтинге DB-Engines я все же упомяну, чтобы не было иллюзий после прочтения статьи. Да, популярность Postgres растет на фоне снижения популярности Oracle/MSSQL/MySQL, но Pg все же далеко до 3-го места, а про лидерство я уж и не говорю.
Все бы хорошо, но следовало бы написать на каком дистрибутиве Linux и с какой версией ядра Вы воспроизводили проблему, прям таблично.
Если не ошибаюсь, у Oracle Linux применена куча дополнительных патчей на ядро (UEK ядра linux) именно для XFS и даже если там предполагается что ядро с багом, то не факт что он есть на самом деле именно в Oracle Linux. То же касается и RedHat.
Кажеться, что слишком много телодвижений + бэкап должен быть в таком формате чтобы максимально быстро можно было на нем запустить пг и тут возникает вопрос: А если за сутки у вас архивируется 100Tb wal файлов и инкрементальный бэкап пусть даже 1 раз в сутки, то скажем востановиться на 23:47:12 это нужно накатить примерно 50Tb валов до нужной точки - сколько Вы будите накатывать их? Как решается такая проблема?
На фоне приседаний многих компаний выпускающих энтерпрайзные postgres для 1С у меня возник вопрос:
Это феномен чисто Российский когда компания производитель СУБД оптимизирует СУБД под конкретный софт (под 1С) или это имеет место быть и в других кровавых Ынтерпрайзах типа MSSQL/Oracle ?
Если ли другие производители СУБД (MSSQL/Oracle) подстраивают свой разработки под конкретный софт, то можно еще примеры под какой софт они подстраиваются?
pg_dump делает логическую копию, не физическую и в этом вся тонкость. И да, он не годиться для больших продакшен баз данных где важна скорость, инкрементные бэкапы, PITR (восстановление на точку во времени), шифрование и прочее.
Чем? Можете привести примеры, в которых такой подход привёл к негативным последствиям?
У вас в одной куче stateful сервис (это база) и stateless (сервис). Что будет если oom-killer решит прибить контейнер с этой кучей сервисов? База может крэшнуться и не запуститься в следующий раз, может еще что-то нехорошее приключиться.
А захардкоженый пароль пользователя postgres, так задумано? Мне тоже объяснить к чему это может привести или сами догадаетесь? Ну сделайте хоть рандом, это не сложно. Про то что у Вас приложение работает с БД под пользователем postgres я тоже умолчу, для меня как для ДБА со стажем - это как минимум странно.
И я не понимаю, что мешало запускать ваш сервис через Docker Compose где база будет в отдельном контейнере, а сервис, пусть и с набором бинарников pg_dump в отдельном? Зачем базу держать рядом с приложением? Это 2 разные сущности.
А если в БД обнаружиться критическая уязвимость, то как ее обновить в такой куче мала?
А если я хочу отказоустойчивую БД с репликами и прочими прелестями то как быть?
А если я хочу PostgreSQL 18 (у вас внутри 17-я версия), то что делать?
Ответьте мне на эти вопросы пожалуйста. Просто ответе, без холивара.
3) Обосрали проект. Не рассказав, какое решение сопоставимого размера вы выложили в open source и принесли сопоставимую пользу людям.
Я не обсирал Ваш проект, поставил ему звезду и добавил в закладки в надежде, что Вы примите во внимание как минимум 2 комментария про то что было бы неплохо иметь отдельные бинарники и краткую инструкцию как их запустить без докера и встроенной БД, но у вас это вызывает бурю негодования, что это какие-то сложности, нарушит пользовательский опыт и прочие отговорки. Печально.
В предыдущей статье в комментариях некоторые люди спрашивали как настроить работу вашей программы через IaC. Ну как бы 21-й век, все описывают инфраструктуру как код, чтобы можно было деплоить все одинаково настроенное в разные проекты. Но Вы пропустили мимо эти комментарии, они не важны, печально.
>Легко критиковать усилия других людей, не выставляя свои решения напоказ.
А причем тут мои решения? Речь не про них, речь про Ваш продукт, не переводите разговор на другую тему. Почитайте, что я написал повнимательней. Альтернативы Вашему решения есть, вот пожалуйста gobackup, один бинарник, все умеет, никаких зависимостей.
>Я посмотрел ваш GitHub
Зачем его смотреть? Ну реально? Речь не обо мне, а о Вашем проекте. Повторюсь, я написал несколько вопросов выше. Очень хочется чтобы Вы на них ответили четко и по делу, не переходя на личности и достижения.
Напихать все в одну кучу (докер-образ) нарушив все принципы проектирования Вы конечно можете. Чем это обернется? Покажет время. Лично я не стану использовать такой продукт и рекомендовать его кому-то так же не стану, как накопленная поделка сгодится, но не более, при всем моем уважении. Альтернативы есть, причем довольно неплохие.
Фронт и бэк легко можно засунуть в 1 бинарник. Бд для сервиса это служебная часть и она может и должна быть за пределами контейнера с приложением, запускаете приложение - оно идет в бд и если там пусто то запускает миграции и создает все нужные объекты. Служебные бинарники pg_dump так же нет смысла постоянно держать рядом с программой, можно скачивать их из офф репо дистрибутива ос и обновлять, что тоже важно тк в сторонних утилитах находят уязвимости и баги и их нужно обновлять
Планируется ли сделать github ci/cd для тестов (а они есть?) и для создания готовых сборок под разные ОС? А то как-то ИМХО пока без наличия автоматизации сборки и тестирования страшновато использовать Ваш продукт, хоть он и кажется более функциональным чем nekoray или hiddify
Наверно нужно уточнить что это Azure PostgreSQL и я уверен, что от ванилы она оооочень сильно отличается. И это вероятно одна из важных составляющих.
Честно говоря - ничего нового, все те же рецепты и подходы что и 10 лет назад
Спасибо за статью. Не увидел в ней или пропустил хоть что-то про техническую поддержку вендора уровня enterprise с выездом инженера на место установки для замены вдруг вышедших из строя блоков (а это вообще поддерживается?). Без такого рода поддержки, какая бы железка не была живучей и отказоустойчивой, но практика показывает, что ломается даже то, что казалось бы не может ломаться.
Думаю это коммерческая тайна и никогда не выйдет наружу. Да и зачем, если честно?
Жаль, что в статье нет ничего про проект шардированного Postgres SPQR от Yandex
Проект довольно зрелый в отличии от Multigres
Ну и про то что Postgres никогда не поднимался выше MySQL в рейтинге DB-Engines я все же упомяну, чтобы не было иллюзий после прочтения статьи. Да, популярность Postgres растет на фоне снижения популярности Oracle/MSSQL/MySQL, но Pg все же далеко до 3-го места, а про лидерство я уж и не говорю.
Я тоже жду версию без докера или хотя бы чтобы сервисная БД была в отдельном от приложения контейнере.
XFS разработал Silicon Graphics, к Oracle она имеет отношение только как дефолтная ФС используемая в Oracle Linux.
Все бы хорошо, но следовало бы написать на каком дистрибутиве Linux и с какой версией ядра Вы воспроизводили проблему, прям таблично.
Если не ошибаюсь, у Oracle Linux применена куча дополнительных патчей на ядро (UEK ядра linux) именно для XFS и даже если там предполагается что ядро с багом, то не факт что он есть на самом деле именно в Oracle Linux. То же касается и RedHat.
Кажеться, что отстающая реплика на N часов более интересное решение, хотя и более накладное с точки зрения потребления ресурсов.
Кажеться, что слишком много телодвижений + бэкап должен быть в таком формате чтобы максимально быстро можно было на нем запустить пг и тут возникает вопрос: А если за сутки у вас архивируется 100Tb wal файлов и инкрементальный бэкап пусть даже 1 раз в сутки, то скажем востановиться на 23:47:12 это нужно накатить примерно 50Tb валов до нужной точки - сколько Вы будите накатывать их? Как решается такая проблема?
Спасибо за статью, очень полезно!
Спасибо
Спасибо за патч! А можно ссылочку на commit fest где приняли патч?
На фоне приседаний многих компаний выпускающих энтерпрайзные postgres для 1С у меня возник вопрос:
Это феномен чисто Российский когда компания производитель СУБД оптимизирует СУБД под конкретный софт (под 1С) или это имеет место быть и в других кровавых Ынтерпрайзах типа MSSQL/Oracle ?
Если ли другие производители СУБД (MSSQL/Oracle) подстраивают свой разработки под конкретный софт, то можно еще примеры под какой софт они подстраиваются?
pg_dump делает логическую копию, не физическую и в этом вся тонкость. И да, он не годиться для больших продакшен баз данных где важна скорость, инкрементные бэкапы, PITR (восстановление на точку во времени), шифрование и прочее.
У вас в одной куче stateful сервис (это база) и stateless (сервис). Что будет если oom-killer решит прибить контейнер с этой кучей сервисов? База может крэшнуться и не запуститься в следующий раз, может еще что-то нехорошее приключиться.
А захардкоженый пароль пользователя postgres, так задумано? Мне тоже объяснить к чему это может привести или сами догадаетесь? Ну сделайте хоть рандом, это не сложно. Про то что у Вас приложение работает с БД под пользователем postgres я тоже умолчу, для меня как для ДБА со стажем - это как минимум странно.
И я не понимаю, что мешало запускать ваш сервис через Docker Compose где база будет в отдельном контейнере, а сервис, пусть и с набором бинарников pg_dump в отдельном? Зачем базу держать рядом с приложением? Это 2 разные сущности.
А если в БД обнаружиться критическая уязвимость, то как ее обновить в такой куче мала?
А если я хочу отказоустойчивую БД с репликами и прочими прелестями то как быть?
А если я хочу PostgreSQL 18 (у вас внутри 17-я версия), то что делать?
Ответьте мне на эти вопросы пожалуйста. Просто ответе, без холивара.
Я не обсирал Ваш проект, поставил ему звезду и добавил в закладки в надежде, что Вы примите во внимание как минимум 2 комментария про то что было бы неплохо иметь отдельные бинарники и краткую инструкцию как их запустить без докера и встроенной БД, но у вас это вызывает бурю негодования, что это какие-то сложности, нарушит пользовательский опыт и прочие отговорки. Печально.
В предыдущей статье в комментариях некоторые люди спрашивали как настроить работу вашей программы через IaC. Ну как бы 21-й век, все описывают инфраструктуру как код, чтобы можно было деплоить все одинаково настроенное в разные проекты. Но Вы пропустили мимо эти комментарии, они не важны, печально.
>Легко критиковать усилия других людей, не выставляя свои решения напоказ.
А причем тут мои решения? Речь не про них, речь про Ваш продукт, не переводите разговор на другую тему. Почитайте, что я написал повнимательней. Альтернативы Вашему решения есть, вот пожалуйста gobackup, один бинарник, все умеет, никаких зависимостей.
>Я посмотрел ваш GitHub
Зачем его смотреть? Ну реально? Речь не обо мне, а о Вашем проекте. Повторюсь, я написал несколько вопросов выше. Очень хочется чтобы Вы на них ответили четко и по делу, не переходя на личности и достижения.
Напихать все в одну кучу (докер-образ) нарушив все принципы проектирования Вы конечно можете. Чем это обернется? Покажет время. Лично я не стану использовать такой продукт и рекомендовать его кому-то так же не стану, как накопленная поделка сгодится, но не более, при всем моем уважении. Альтернативы есть, причем довольно неплохие.
Фронт и бэк легко можно засунуть в 1 бинарник. Бд для сервиса это служебная часть и она может и должна быть за пределами контейнера с приложением, запускаете приложение - оно идет в бд и если там пусто то запускает миграции и создает все нужные объекты. Служебные бинарники pg_dump так же нет смысла постоянно держать рядом с программой, можно скачивать их из офф репо дистрибутива ос и обновлять, что тоже важно тк в сторонних утилитах находят уязвимости и баги и их нужно обновлять
Эмммм, у Вас там не один бинарник? почему нельзя без докера? А если я не хочу докер, ну банально ресурсы не позволяют этот слоеный пирог запустить.
Планируется ли сделать github ci/cd для тестов (а они есть?) и для создания готовых сборок под разные ОС? А то как-то ИМХО пока без наличия автоматизации сборки и тестирования страшновато использовать Ваш продукт, хоть он и кажется более функциональным чем nekoray или hiddify