Ха битая память) Реальность то по-хлеще будет. Был такой старый баг, сложно найти, но следы еще остались в нете : 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 все инстансы высконагруженные.
первые 5 лет мы только вкладывали в бизнес и шли к показателю 100 млн крышечек в месяц, как ослик за морковкой. Меньше 100 млн крышек в месяц производить нерентабельно. Под эти объемы нужны большие площади, дорогое оборудование, квалифицированные технологи, что равно огромные инвестиции.
Статья хорошая, но не хвататет детали, чтобы пазл сложился. Где вы взяли 1,5 миллиарда чтобы открыть большой завод , если до этого бизнес был убыточный ?
Вместо log_min_duration_statement советую pg_store_plans https://ossc-db.github.io/pg_store_plans/ все таки родной sql , это гораздо удобнее чем запись планов в логфайл (особенно, если у вас приличные нагрзуки). И (позвольте немного попиарюсь) к этому , еще прикрутил историю сессий - https://habr.com/ru/companies/uzum/articles/865622/ , и получил практически awr оракловый ). Так что можно жить и с Postgres, просто тут принцип другой, минимум - из коробки.
Автоматизацию для pg_repack на нем делал с вызовом из pg_cron. Зачем-то его реализовали как внешний исполняемый файл, хотя его лоичней из бд вызывать, используя стату для определения bloat таблиц .
Ребят, ну вы хоть комментарии давайте что у вас конфиг на файловер с легитимной потерей данных. Наверное из за таких статей и встречаю в продах такие вот конфиги.
Ха битая память) Реальность то по-хлеще будет.
Был такой старый баг, сложно найти, но следы еще остались в нете :
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 прекрасно работает с партициями.
Статья хорошая, но не хвататет детали, чтобы пазл сложился. Где вы взяли 1,5 миллиарда чтобы открыть большой завод , если до этого бизнес был убыточный ?
Вместо log_min_duration_statement советую pg_store_plans
https://ossc-db.github.io/pg_store_plans/ все таки родной sql , это гораздо удобнее чем запись планов в логфайл (особенно, если у вас приличные нагрзуки).
И (позвольте немного попиарюсь) к этому , еще прикрутил историю сессий - https://habr.com/ru/companies/uzum/articles/865622/ , и получил практически awr оракловый ). Так что можно жить и с Postgres, просто тут принцип другой, минимум - из коробки.
Вроде более удобным способом можно удалять гланды - https://postgreshelp.com/postgresql-checksum/?source=post_page-----33806f44b1c4-------------------------------
Хотя, честно говоря, сам
таким еще не страдалне пробовал - т.к. бэкапы, enabled pg_checksum, и standby db для критичных данных.Автоматизацию для pg_repack на нем делал с вызовом из pg_cron. Зачем-то его реализовали как внешний исполняемый файл, хотя его лоичней из бд вызывать, используя стату для определения bloat таблиц .
Ребят, ну вы хоть комментарии давайте что у вас конфиг на файловер с легитимной потерей данных. Наверное из за таких статей и встречаю в продах такие вот конфиги.
Изначальный выбор Оракла, просто как хранилку данных шарда, без логики.. выглядет кхм.. не совсем рационально.