Сколько уже лет эта тема движется? 5 или 7? Когда же наконец будет хоть какой-то сдвиг в ваниле? Я честно говоря уже потерял все треды где там патч с поддержкой 64-битного счетчика пытаются ребейзить до текущей версии пг и оттестировать. 2 человека что-ли над этим работают, кажется что это очень мало и даже в 20-й версии пг мы не увидим полностью 64-битный счетчик во всех местах.
Оркестратор в офф репе https://github.com/github/orchestrator не развивается и не будет развиваться больше, репа в архивном режиме, так что я бы не стал его использовать.
Есть форк от Percona https://github.com/percona/orchestrator но и он официально не является сопровождаемым, но там хотя бы исправляют хоть какие-то найденный ошибки.
Если Вы не умеете готовить мускуль и правильно писать запросы, делать DDL, то и на постгрес Вы словите такого же рода проблемы просто в другом месте. С любой БД можно подскользнуться и больно упасть если не вникать в тонкости и нюансы работы базы. Речь конечно про хайлоад, а не пет-проект с 10 посетителями в час.
Если у Вас есть интернет-магазин на стареньком Bitrix с базенкой на 5.7 то вы даже на минорное обновление 5.7 не поднимитесь, тк версия мускуля прибивается гвоздями к версии битрикса. Ну про миграцию на новую версию битрикса и новый мажорный мускуль думаю не нужно объяснять - это довольно большие деньги для компании. Так что многие сидят на старом мускуле.
Спасибо за статью. Не увидел в ней или пропустил хоть что-то про техническую поддержку вендора уровня 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 валов до нужной точки - сколько Вы будите накатывать их? Как решается такая проблема?
Нейронка глюканула наверно)
Сколько уже лет эта тема движется? 5 или 7? Когда же наконец будет хоть какой-то сдвиг в ваниле? Я честно говоря уже потерял все треды где там патч с поддержкой 64-битного счетчика пытаются ребейзить до текущей версии пг и оттестировать. 2 человека что-ли над этим работают, кажется что это очень мало и даже в 20-й версии пг мы не увидим полностью 64-битный счетчик во всех местах.
Кажется что это классический подход используемый в Serverless, но со своими прихватами в виде Parquet
Что-то типа Neon Serverless Postgres или иных решений на базе Neon
Оркестратор в офф репе https://github.com/github/orchestrator не развивается и не будет развиваться больше, репа в архивном режиме, так что я бы не стал его использовать.
Есть форк от Percona https://github.com/percona/orchestrator но и он официально не является сопровождаемым, но там хотя бы исправляют хоть какие-то найденный ошибки.
Спасибо, всегда приятно читать технические аспекты реализации!
glib нет на любом утюге, а postgres там нужно запускать
А где же видос как она ездит?
Если Вы не умеете готовить мускуль и правильно писать запросы, делать DDL, то и на постгрес Вы словите такого же рода проблемы просто в другом месте. С любой БД можно подскользнуться и больно упасть если не вникать в тонкости и нюансы работы базы. Речь конечно про хайлоад, а не пет-проект с 10 посетителями в час.
Если у Вас есть интернет-магазин на стареньком Bitrix с базенкой на 5.7 то вы даже на минорное обновление 5.7 не поднимитесь, тк версия мускуля прибивается гвоздями к версии битрикса. Ну про миграцию на новую версию битрикса и новый мажорный мускуль думаю не нужно объяснять - это довольно большие деньги для компании. Так что многие сидят на старом мускуле.
2025-09
ведет на
https://habr.com/ru/companies/postgrespro/articles/986694/
а там
403
Материал был снят с публикации автором. Возможно он опубликует его после доработки.
Наверно нужно уточнить что это 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 валов до нужной точки - сколько Вы будите накатывать их? Как решается такая проблема?