Все бы хорошо, но следовало бы написать на каком дистрибутиве 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
Перевод оффицальных мануалов тоже полезен, хотя бы новичкам.
P.S. Авторам - кажеться, что огромные скрины Google Authenticator (и другие) это излишне, честно очень неудобно скролировать такую статью где банальный скрин (еще и полностью или частично заретуширован) занимает 2 экрана на 2k мониторе.
Работая в прошлом в банке с АБС на oracle был кейс что в бд хранились файлы с образцами подписей клиентов. Файлы занимают сущие копейки и хранить их в бд кажется логичным, тем более оракл это умел.
Если изначально таблица была на 1 шарде, а потом мы сказали роутеру что она стала референсной, то на другие шарды она заедет сама или все же ручками нужно ее копировать во все шарды?
А что будет если сделать UPDATE/DELETE/INSERT по этой таблице? Она по всем шардам бахнет запросы? Это я про поддержание таблицы в консистентном состоянии на всех шардах.
>> SELECT * FROM users LIMIT 1; -- возвращается столько пользователей, сколько шардов.
Это конечно неожиданное поведение. Хотя если явно говорите, что во всех запросах должен быть ключ шардирования, то вроде как логично что результат будет такой, НО все равно не логично.
И у MySQL его нету, по факту Vitess имеет некоторые неявные ограничения, а количество специалистов по нему (те кто реально поддерживал промышленный Vitess) стремиться к нулю. Так что я считаю, что для MySQL тоже нет решения.
Я тоже жду версию без докера или хотя бы чтобы сервисная БД была в отдельном от приложения контейнере.
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
Перевод оффицальных мануалов тоже полезен, хотя бы новичкам.
P.S. Авторам - кажеться, что огромные скрины Google Authenticator (и другие) это излишне, честно очень неудобно скролировать такую статью где банальный скрин (еще и полностью или частично заретуширован) занимает 2 экрана на 2k мониторе.
Работая в прошлом в банке с АБС на oracle был кейс что в бд хранились файлы с образцами подписей клиентов. Файлы занимают сущие копейки и хранить их в бд кажется логичным, тем более оракл это умел.
Если изначально таблица была на 1 шарде, а потом мы сказали роутеру что она стала референсной, то на другие шарды она заедет сама или все же ручками нужно ее копировать во все шарды?
А что будет если сделать UPDATE/DELETE/INSERT по этой таблице? Она по всем шардам бахнет запросы? Это я про поддержание таблицы в консистентном состоянии на всех шардах.
>> SELECT * FROM users LIMIT 1; -- возвращается столько пользователей, сколько шардов.
Это конечно неожиданное поведение. Хотя если явно говорите, что во всех запросах должен быть ключ шардирования, то вроде как логично что результат будет такой, НО все равно не логично.
>у MySQL есть готовое решение, а у Postgres нет.
И у MySQL его нету, по факту Vitess имеет некоторые неявные ограничения, а количество специалистов по нему (те кто реально поддерживал промышленный Vitess) стремиться к нулю. Так что я считаю, что для MySQL тоже нет решения.
Есть кстате ProxySQL который с 3-й версии научился проксировать PostgreSQL, то есть по сути можно что-то сделать на нем. Но как оно работает я не проверял.