Lost update проходит молча, и чинить его приходится самостоятельно
Почему в стандарте SQL, который реализует PostgreSQL, пишут "The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost."?
да, каждая таблица в соединении в 3,4-3.8 раз увеличивает и память и время планирования. Написал про это отдельной статьёй https://habr.com/ru/articles/1038762/ (текста было много). Но 20 разумна, главное не отключать и не увеличивать geqo_threshold (при 16 - 16Гб,дальше увеличение на единицу увеличит память в 3,4 раза больше)
Включаем опцию enable_background_freezer. При частом создании и удалении большого количества временных таблиц autovacuum может не успевать очищать данные системных таблиц, что приводит к их распуханию (bloating). Background freezer очищает удалённые записи на страницах в памяти и «разрастание» системных таблиц существенно уменьшается
Каждое изменение улучшало и APDEX и утилизацию CPU и IO.
был же включён параметр enable_temp_memory_catalog, действие которого состоит в том, что при создании, удалении, усечении временных объектов, в таблицах системного каталога не меняется, не добавляется, не удаляется ни одна строка.
Телемост до сих пор поджаривает процессора или исправили? Без издевки, просто интересно как так случилось. Год-два назад несколько раз пользовался, ноутбуки часто выключались: перегрев, батарея села, тротлинг мешал. Была бы интересна история фэйла, как менеджер проекта с этим пытался справиться и пытался ли. Диск, почта работают отлично (кроме маркетинговых экспериментов с аутентификацией и картинкой с острова Пасхи), но Телемост удивил.
Странно, что ваш пост никто не лайкнул. Про завершение проекта pgBackRest я узнал из вашего поста. Хотя я не работал с Backrest, но прекращение долгих и не самых плохих проектов вызывают лёгкую грусть. Недавно была статья, где хвалили бэкрест и был перевод статьи Самохвалова со сравнением pg_basebackup и backrest, откуда я и узнал, что pgBackRest неплох. Вывод, конечно, там был что pg_basebackup всё быстрее и быстрее бэкапит и в 18 версии в 3 раза ускорился, но если скорости не хватает, то есть решения. В таблицу я бы добавил строки про поддержку режима pull и отсутствие потерь при восстановлении (rpo=0).
Политики удаления (бэкапов и ненужных оставшимся бэкапам архивов журналов) есть: retain (аналог redundancy), before (аналог recovery window), everything, target. Пример удаления всех бэкапов, кроме двух последних. Команда wal-g delete retain 2 --confirm
ещё можно предположить, что когда автовакуум стал делать заморозку (100 млн. транзакций, то есть через какое то время после начала работы архивации) стал сталкиваться с конфликтом на закреплении буферов, из-за чего дольше обрабатывал таблицы, что приводило к раздуванию. Вдобавок, сам автовакуум держит горизонт базы, пока обрабатывает таблицу, что не дает серверным процессам выполнять быструю очистку блоков. Поэтому, стараются, чтобы автовакуум работал быстрее, убирая или уменьшая задержки, компенсируют уменьшением числа процессов, если их было много. Логи кластера могли бы помочь выяснить вероятную причину.
Мне redefiniton в оракл не нравился, но как видно его идея востребована. 👐 В dbms_redefinition полезная мелочь: изменения копятся, пока таблица перегружается. За время перегрузки может накопиться много изменений, поэтому предусмотрена «промежуточная синхронизация» - накопленные загружаются несколько раз, пока последняя перегрузка не пройдет за приемлемо короткое время (секунда например) и тогда исходная таблица блокируется, остаток перегружается, таблицы переименовываются.
Мне тоже pgcompacttable понравился - не требует места. С ним нюанс: нельзя отключать vacuum truncate (параметр old_snapshot_threshold до 17 версии, vacuum_truncate после) он сам не уменьшает файлы, за него это вакуум делает.
Игорь Мельников выложил код dbms_redefinition для PostgreSQL, лицензия Apache 2.0. Там есть и промежуточная синхронизация, что уменьшает простой при больших объемах.
Преимущество в том, что в статье пример кода, а код Мельникова законченный и работоспособный. Написан на pl/pgsql - несложно доработать, есть документация, и доклад, как использовать его код: rutube и youtube
число апдейтов, наверное, не менялось. Скорее всего, при архивации удерживался горизонт базы. Строки, не вышедшие за горизонт, удаляться не могут ни автоваккумом, ни быстрой очисткой. В архивации, скорее всего, горизонт удеживается долгой транзакцией или долгим selectом или был анонимный plpgsql блок с циклом, который порождал долгую транзакцию.
Если бы проблема была в автовакууме, то это было бы видно по логу кластера, так как если автовакуум вакуумирует таблицу дольше 10 минут, по умолчанию (параметр log_autovacuum_min_duration), создается запись в логе. Если, конечно, лог промышленной базы администраторами мониторился. 🙂 Изза удержания, скорее всего, быстрая очистка переставала очищать блоки.
О горизонте базы написано в книге Егора Рогова «PostgreSQL изнутри»
106 и 174 страницы
Долгие (в том числе читающие) запросы удерживают горизонт базы, так как чтобы они не сбойнули со snapshot too old, по всей базе должны удерживаться старые версии строк.
После раздувания сжать сложно. Вы изобрели dbms_redefinition. О нем был доклад Мельникова , он планировал выдожить свой код, но вроде не выложил.
pg_repack — расширение Postgres Pro Enterprise, которое делает аналогичные операции, что и VACUUM FULL и CLUSTER, но выполняет их на ходу без эксклюзивных блокировок таблиц;
по ссылке написано: "pg_repack — это альтернативная ветвь развития проекта https://github.com/reorg/pg_reorg" и на гитхабе написано, что у расширения есть авторы, которые трудились, создавая его:
NIPPON TELEGRAPH AND TELEPHONE CORPORATION Itagaki Takahiro The Reorg Development Team
Авторы отдали расширение в свободный доступ с условием:
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentationand/or other materials provided with the distribution.
В документации нет этого дисклеймера (что допустимо), но есть ссылка, по которой несложно увидеть авторов и само расширение. В статье можно было бы написать, что есть свободно распространяемое расширение pg_repack (2224 звёзды гитхаба), которое дорабатывается и доступно всем.
пересмотрел доклад. pg_probackup3 НЕ выложили в открытый доступ. Меня смутил этот слайд про какую-то "community версию":
Словами в докладе было сказано: “есть открытая freeware версия probackup3 на нашем репозитории. Берите, пользуйтесь, можно скачать.”
Но freeware это совсем не open source, я не нашёл этот “репозиторий”, гугли о нём не знает, специалисты рекомендуют PGBackRest.
Я считаю, что в реляционных базах всё должно быть точно, стабильно, без фраз, которые можно двояко толковать, такие фразы создают антирекламу продукту.
pgcompacttable. Он требует меньше места
можно поподробнее что имеете в виду? это же не Throwable
Почему в стандарте SQL, который реализует PostgreSQL, пишут "The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost."?
вот вроде https://cp.vdsina.com/
можно без файлов sql, control, без create extension? достаточно ли просто загрузить библиотеку? можно ли загрузить командой load?
да, конечно, oom это если geqo=off или geqo_threshold увеличен и вместе с запросом и collapse_limit пооучается, что выделяется много памяти
да, каждая таблица в соединении в 3,4-3.8 раз увеличивает и память и время планирования. Написал про это отдельной статьёй https://habr.com/ru/articles/1038762/ (текста было много). Но 20 разумна, главное не отключать и не увеличивать geqo_threshold (при 16 - 16Гб,дальше увеличение на единицу увеличит память в 3,4 раза больше)
был же включён параметр enable_temp_memory_catalog, действие которого состоит в том, что при создании, удалении, усечении временных объектов, в таблицах системного каталога не меняется, не добавляется, не удаляется ни одна строка.
Может enable_background_freezer давал эффект на чем то другом?
Привозит мужик тёщу в реанимацию.Через час выходит доктор:
- Мне очень жаль, но ваша тёща умерла.
Мужик убивается, плачет. Через некоторое время врач возвращается смущённый:
- Мы перепутали, ваша тёща жива, состояние стабильное.
Мужик встрепенулся и в возмущении:
- Нет уж! Умерла так умерла.
Телемост до сих пор поджаривает процессора или исправили? Без издевки, просто интересно как так случилось. Год-два назад несколько раз пользовался, ноутбуки часто выключались: перегрев, батарея села, тротлинг мешал. Была бы интересна история фэйла, как менеджер проекта с этим пытался справиться и пытался ли. Диск, почта работают отлично (кроме маркетинговых экспериментов с аутентификацией и картинкой с острова Пасхи), но Телемост удивил.
Странно, что ваш пост никто не лайкнул. Про завершение проекта pgBackRest я узнал из вашего поста. Хотя я не работал с Backrest, но прекращение долгих и не самых плохих проектов вызывают лёгкую грусть. Недавно была статья, где хвалили бэкрест и был перевод статьи Самохвалова со сравнением pg_basebackup и backrest, откуда я и узнал, что pgBackRest неплох. Вывод, конечно, там был что pg_basebackup всё быстрее и быстрее бэкапит и в 18 версии в 3 раза ускорился, но если скорости не хватает, то есть решения. В таблицу я бы добавил строки про поддержку режима pull и отсутствие потерь при восстановлении (rpo=0).
Политики удаления (бэкапов и ненужных оставшимся бэкапам архивов журналов) есть: retain (аналог redundancy), before (аналог recovery window), everything, target. Пример удаления всех бэкапов, кроме двух последних. Команда
wal-g delete retain 2 --confirmпланировщик есть в Платформе Тантор, можно использовать cron.
Можно написать скрипт, можно отдельными командами:
wal-g backup-push $PGDATA -fwal-g delete retain2--confirmфпятерке!
да, эпоха свободы! Статьи Лурка остались, может законсервируют и оставят образ сайта для истории. Это культурное явление, как Бивис и Батхед.
перед последней скобкой «)» тоже нужен пробел :)
если пробела нет, то считается новым параметром, получится у того парамертра, что выше нет закрывающей скобки и параметр из одной скобки тоже неверен
ещё можно предположить, что когда автовакуум стал делать заморозку (100 млн. транзакций, то есть через какое то время после начала работы архивации) стал сталкиваться с конфликтом на закреплении буферов, из-за чего дольше обрабатывал таблицы, что приводило к раздуванию. Вдобавок, сам автовакуум держит горизонт базы, пока обрабатывает таблицу, что не дает серверным процессам выполнять быструю очистку блоков. Поэтому, стараются, чтобы автовакуум работал быстрее, убирая или уменьшая задержки, компенсируют уменьшением числа процессов, если их было много. Логи кластера могли бы помочь выяснить вероятную причину.
Мне redefiniton в оракл не нравился, но как видно его идея востребована. 👐 В dbms_redefinition полезная мелочь: изменения копятся, пока таблица перегружается. За время перегрузки может накопиться много изменений, поэтому предусмотрена «промежуточная синхронизация» - накопленные загружаются несколько раз, пока последняя перегрузка не пройдет за приемлемо короткое время (секунда например) и тогда исходная таблица блокируется, остаток перегружается, таблицы переименовываются.
Мне тоже pgcompacttable понравился - не требует места. С ним нюанс: нельзя отключать vacuum truncate (параметр old_snapshot_threshold до 17 версии, vacuum_truncate после) он сам не уменьшает файлы, за него это вакуум делает.
Либо всё одной строкой, либо вначале хотябы один пробел на всех строках, кроме первой :)
Игорь Мельников выложил код dbms_redefinition для PostgreSQL, лицензия Apache 2.0. Там есть и промежуточная синхронизация, что уменьшает простой при больших объемах.
https://github.com/IgorM24/DBMS_REDEFINITION
Преимущество в том, что в статье пример кода, а код Мельникова законченный и работоспособный. Написан на pl/pgsql - несложно доработать, есть документация, и доклад, как использовать его код: rutube и youtube
число апдейтов, наверное, не менялось. Скорее всего, при архивации удерживался горизонт базы. Строки, не вышедшие за горизонт, удаляться не могут ни автоваккумом, ни быстрой очисткой. В архивации, скорее всего, горизонт удеживается долгой транзакцией или долгим selectом или был анонимный plpgsql блок с циклом, который порождал долгую транзакцию.
Если бы проблема была в автовакууме, то это было бы видно по логу кластера, так как если автовакуум вакуумирует таблицу дольше 10 минут, по умолчанию (параметр log_autovacuum_min_duration), создается запись в логе. Если, конечно, лог промышленной базы администраторами мониторился. 🙂 Изза удержания, скорее всего, быстрая очистка переставала очищать блоки.
О горизонте базы написано в книге Егора Рогова «PostgreSQL изнутри»
Долгие (в том числе читающие) запросы удерживают горизонт базы, так как чтобы они не сбойнули со snapshot too old, по всей базе должны удерживаться старые версии строк.
После раздувания сжать сложно. Вы изобрели dbms_redefinition. О нем был доклад Мельникова , он планировал выдожить свой код, но вроде не выложил.
по ссылке написано: "pg_repack — это альтернативная ветвь развития проекта https://github.com/reorg/pg_reorg" и на гитхабе написано, что у расширения есть авторы, которые трудились, создавая его:
NIPPON TELEGRAPH AND TELEPHONE CORPORATIONItagaki Takahiro
The Reorg Development Team
Авторы отдали расширение в свободный доступ с условием:
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
В документации нет этого дисклеймера (что допустимо), но есть ссылка, по которой несложно увидеть авторов и само расширение. В статье можно было бы написать, что есть свободно распространяемое расширение pg_repack (2224 звёзды гитхаба), которое дорабатывается и доступно всем.
pgcompacttable написал Максим Богук
пересмотрел доклад. pg_probackup3 НЕ выложили в открытый доступ. Меня смутил этот слайд про какую-то "community версию":
Словами в докладе было сказано: “есть открытая freeware версия probackup3 на нашем репозитории. Берите, пользуйтесь, можно скачать.”
Но freeware это совсем не open source, я не нашёл этот “репозиторий”, гугли о нём не знает, специалисты рекомендуют PGBackRest.
Я считаю, что в реляционных базах всё должно быть точно, стабильно, без фраз, которые можно двояко толковать, такие фразы создают антирекламу продукту.