В перспективе развития разработчики обещают: сначала добить самые популярные пакеты, а в горизонте пары лет закрыть и редко используемые.
До серьезной enterprise ready совместимости там пока еще очень далеко, так я понял? И соответственно, реальных миграций проектов с большим объемом stored кода в БД на нее нет ? Или есть ? А так, ждем, будем посмотреть, как показывает опыт китайцев/корейцев, подход имеет место.
Вроде для подобных вещей AWX с constructed Inventory и задумывался. Вы его вскольз упоминаете но дальше рассказывете как пилите свой костыль. Почему не используете ? Тоже все больше становиться похожих inventory-ориенторированных задач, смотрю в его сторону и вроде как по функционалу на бумаге подходит.. Что-то там не так ?
С этими графическими системами есть проблема. Большинство из них слабо годятся для хорошего пост-мортена, так как не решают простой кейс, с которым DBA часто сталкивается : если запрос долго работал из-за блокировки - то показать, кто блокировал запрос и историю сессии блокировщика. Вот и получается, что нужна нормальная табличная история pg_stat_activity и pg_locks. Pg_locks вообще далеко не все собирают. Все, пилим свой gatherer. А для алертов заббик вполне норм, нормально он масштабируется, готовить просто надо уметь, (как и все остальное впрочем). А из всех этих красивых панелей реально нужны масимум 2-3, которые можно и самому в grafana за час наклепать, максимально удобно под свои нужды.
В больших проектах логи сами по себе превращаются в отдельный проект. Некоторые команды выбирают самостоятельный хостинг и организацию запросов к логам.
прикрутил vector , и складирую в opensearch (так как он уже был) впринципе, вполне удобно(и бюджетно) получилось для enterprise объемов.
Ха битая память) Реальность то по-хлеще будет. Был такой старый баг, сложно найти, но следы еще остались в нете : Oracle Bug 10165083 "Wrong child cursor may be executed - SQL executes in a wrong schema". Вот как раз у нас была БД, где по схемам были разбросаны разные организации, а структура внутри схем одинаковая. И оракл при запросе в схему, иногда "честно" выдавал данные из другой. И ТП не признавалась, пока в трейс их носом не ткнули.
Из за битого индекса в структуре Oracle Advanced Queuing оракл падал абсолютно без каких либо следов в логах, трейсах , кор дампов итп ? Какая версия хоть ?
Извините, но за такой уровень - минусанул - низкий технический уровень материала. Где данные о железе, где хотя бы стравнение на нем с ora2pg, другими CDC ? Или это и есть ora2pg с вэбмородой ? .. ну ок , красивое )
В общем то полезно, спс, но .. очередная статья про то как смигрировали оракл без бизнес логики с ora2pg, fdw и track-таблицами... и тестированием после взлета😁
Где же реальные миграции каких нибудь банковских АБС с миллионами строк бизнес логики с разработкой какого нибудь ультра конвевертера plsql в pg/plsql на основе AI, своим CDC, шинами ? Не видно что-то...
В https://github.com/reorg/pg_repack/issues довольно много интересного , и про партиции и про ключи и про триггеры найдется. Я думаю даже авторы не всегда знают как оно отработает) Имхо - репак совсем не enterprise ready, если со средним объемами еще можно справиться, то с более менее большими и нагруженными данными с чуть большей сложностью схемы , чем простые plain tables + индексы - уже все совсем не весело.
Тот же pg_squeeze гораздо лучше, так как позволяет из коробки потоянный процессинг работы с bloat насторить, что в принципе более правильный подход. А pg_repack , ну такое, больше похож на костыль для тушения пожаров, а раз у тебя пожар, значит, ты уже прошляпил.
И еще по моему опыту - если вам нужен регулярно VACUUM FULL, что то у вас с моделью данных не так, где то партиционирование забыли , time-series не используют где можно и нужно итд итп.
Ну, если честно, детский сад какой то ) Есс-но на такое изменение в проде должна быть заявка [в жире] с точным наобором заинтересованных согласующих. А не по чатикам в телеге искать.. вот и результат.. Но это, конечно, не отменяет полезности и интересности статьи, спасибо!
Да, вероятность какого-то влияния низка, но это и не главное, нетворкинг так или иначе работает. Это может сподвигнуть еще десяток человек, где-то зашищать свои права, ну итд по цепочке. Да и закручивание гаек как работает - крутят, смотрят, никто не возмущается, крутят дальше. Поэтому респект, автору что делаешь, а что шаришь опыт - двойной респект!
Как выше написали, какой pgdump, вы о чем ? Название не соотвествует сути. Серьезное копирование должно включать wal-archiving, соотвественно как следствие, уметь PITR, плюс incremental backup (желетально с block change tracking), если у вас хоть сколь-нибудь серьезные объемы. Был barman на там нормального инкрмента нет, но все это есть в pg_probackup. Рекомендую. Берите пока дают, cледующий major уже не будет open (
Короч, и в социализме и в капитализме есть свои плюсы и минусы. Их можно и нужно эффективно сочетать, скандинавы вроде доказали уже. Все расходимся ) PS. А проблемы похоронившие СССР, вообще несколько шире - несменяемость власти, толалитаризм (иногда, в лучшие года переходящий в авторитаризм), плановая милитаризировання экономика... ну итд Люди и в СССР жить хотели, но нет, нате вам только танки. Какой же это социализм ??
RAC обеспечивает одновременно и горизонтальную масштабируемость производительности, и высочайшую доступность на уровне Ну,.. все таки про RAC надо оговариваться что полноценного горизонтального масштабирования он не обеспечивает, IO нагрузка не масштабируется, gc locks при n+1 нод быстро съедают весь профит. При том не совсем понятно, почему автор так грезит RAC для postgres, если на первой же страницы PGPro EE заявлен полноценный Симметричный отказоустойчивый кластер (мультимастер) . Как же так ?
Немного не в тему можно спросить ? 10000 patroni инстансов... zalando (авторы patroni) с 1400 создали свой pg оператор и ушли в k8s. Не рассмотриваете такой вариант ? Врядли у вас там bare metal все инстансы высконагруженные.
Статья про оптимизацию плана без единого плана)
Улыбнуло :
AI и/или лень хоть как то проверить было ?
До серьезной enterprise ready совместимости там пока еще очень далеко, так я понял? И соответственно, реальных миграций проектов с большим объемом stored кода в БД на нее нет ? Или есть ?
А так, ждем, будем посмотреть, как показывает опыт китайцев/корейцев, подход имеет место.
Что за шардированный postgres? У postgres нет (своего) шардирования.
Вроде для подобных вещей AWX с constructed Inventory и задумывался. Вы его вскольз упоминаете но дальше рассказывете как пилите свой костыль. Почему не используете ?
Тоже все больше становиться похожих inventory-ориенторированных задач, смотрю в его сторону и вроде как по функционалу на бумаге подходит.. Что-то там не так ?
С этими графическими системами есть проблема.
Большинство из них слабо годятся для хорошего пост-мортена, так как не решают простой кейс, с которым DBA часто сталкивается :
если запрос долго работал из-за блокировки - то показать, кто блокировал запрос и историю сессии блокировщика.
Вот и получается, что нужна нормальная табличная история pg_stat_activity и pg_locks. Pg_locks вообще далеко не все собирают.
Все, пилим свой gatherer. А для алертов заббик вполне норм, нормально он масштабируется, готовить просто надо уметь, (как и все остальное впрочем).
А из всех этих красивых панелей реально нужны масимум 2-3, которые можно и самому в grafana за час наклепать, максимально удобно под свои нужды.
прикрутил vector , и складирую в opensearch (так как он уже был)
впринципе, вполне удобно(и бюджетно) получилось для enterprise объемов.
Ха битая память) Реальность то по-хлеще будет.
Был такой старый баг, сложно найти, но следы еще остались в нете :
Oracle Bug 10165083 "Wrong child cursor may be executed - SQL executes in a wrong schema".
Вот как раз у нас была БД, где по схемам были разбросаны разные организации, а структура внутри схем одинаковая. И оракл при запросе в схему, иногда "честно" выдавал данные из другой. И ТП не признавалась, пока в трейс их носом не ткнули.
Из за битого индекса в структуре Oracle Advanced Queuing оракл падал абсолютно без каких либо следов в логах, трейсах , кор дампов итп ?
Какая версия хоть ?
Извините, но за такой уровень - минусанул - низкий технический уровень материала.
Где данные о железе, где хотя бы стравнение на нем с ora2pg, другими CDC ? Или это и есть ora2pg с вэбмородой ? .. ну ок , красивое )
В общем то полезно, спс, но .. очередная статья про то как смигрировали оракл без бизнес логики с ora2pg, fdw и track-таблицами... и тестированием после взлета😁
Где же реальные миграции каких нибудь банковских АБС с миллионами строк бизнес логики
с разработкой какого нибудь ультра конвевертера plsql в pg/plsql на основе AI, своим CDC, шинами ? Не видно что-то...
В https://github.com/reorg/pg_repack/issues довольно много интересного , и про партиции и про ключи и про триггеры найдется. Я думаю даже авторы не всегда знают как оно отработает) Имхо - репак совсем не enterprise ready, если со средним объемами еще можно справиться, то с более менее большими и нагруженными данными с чуть большей сложностью схемы , чем простые plain tables + индексы - уже все совсем не весело.
Тот же pg_squeeze гораздо лучше, так как позволяет из коробки потоянный процессинг работы с bloat насторить, что в принципе более правильный подход. А pg_repack , ну такое, больше похож на костыль для тушения пожаров, а раз у тебя пожар, значит, ты уже прошляпил.
И еще по моему опыту - если вам нужен регулярно VACUUM FULL, что то у вас с моделью данных не так, где то партиционирование забыли , time-series не используют где можно и нужно итд итп.
15 Штатов приняли законодательство и хранят часть своих резеров в биткоинах. Не читаеют, видимо, комменты на хабре глупые американцы )
Ну, если честно, детский сад какой то ) Есс-но на такое изменение в проде должна быть заявка [в жире] с точным наобором заинтересованных согласующих. А не по чатикам в телеге искать.. вот и результат..
Но это, конечно, не отменяет полезности и интересности статьи, спасибо!
Да, вероятность какого-то влияния низка, но это и не главное, нетворкинг так или иначе работает. Это может сподвигнуть еще десяток человек, где-то зашищать свои права, ну итд по цепочке. Да и закручивание гаек как работает - крутят, смотрят, никто не возмущается, крутят дальше.
Поэтому респект, автору что делаешь, а что шаришь опыт - двойной респект!
Как выше написали, какой pgdump, вы о чем ? Название не соотвествует сути.
Серьезное копирование должно включать wal-archiving, соотвественно как следствие, уметь PITR, плюс incremental backup (желетально с block change tracking), если у вас хоть сколь-нибудь серьезные объемы.
Был barman на там нормального инкрмента нет, но все это есть в pg_probackup. Рекомендую. Берите пока дают, cледующий major уже не будет open (
Короч, и в социализме и в капитализме есть свои плюсы и минусы.
Их можно и нужно эффективно сочетать, скандинавы вроде доказали уже.
Все расходимся )
PS. А проблемы похоронившие СССР, вообще несколько шире - несменяемость власти, толалитаризм (иногда, в лучшие года переходящий в авторитаризм), плановая милитаризировання экономика... ну итд
Люди и в СССР жить хотели, но нет, нате вам только танки. Какой же это социализм ??
RAC обеспечивает одновременно и горизонтальную масштабируемость производительности, и высочайшую доступность на уровне
Ну,.. все таки про RAC надо оговариваться что полноценного горизонтального масштабирования он не обеспечивает, IO нагрузка не масштабируется, gc locks при n+1 нод быстро съедают весь профит.
При том не совсем понятно, почему автор так грезит RAC для postgres, если на первой же страницы PGPro EE заявлен полноценный Симметричный отказоустойчивый кластер (мультимастер) . Как же так ?
Просто оставлю это здесь
Эксперты связали двукратный рост аудитории Rutube за год с пиратским контентом
Немного не в тему можно спросить ?
10000 patroni инстансов... zalando (авторы patroni) с 1400 создали свой pg оператор и ушли в k8s. Не рассмотриваете такой вариант ? Врядли у вас там bare metal все инстансы высконагруженные.
пора рассказать им про партиционирование )
pg_repack прекрасно работает с партициями.