если не додумывать, страшилок нет. Жирным текстом выделил фразу "Что хорошо". Это как COPY WITH FREEZE - в документации пугают нарушениями видимости, но всё просто, только надо об особенности знать.
Минус по производительности будет, если на Oracle установить Maximum Protection. Он фиксирует транзакцию, если журнальная зпись передана резервной базе (SYNC) + резервная база записала журнальную запись на диск (AFFIRM). Maximum Availability допускат "fastsync" - (SYNC NOAFFIRM). Фаст значит быстрый, его и используют. Этот режим преедачи журналов и выставляют и для Maximum Availability и для Maximum Performance. Режим передачи не зависит от режима защиты, можно стаить как угодно.
В PostgreSQL аналогично: synchronous_commit=on, это абсолютно то же самое, что в Oracle SYNC AFFIRM - работает медленно. Если установить synchronous_commit=remote_write , то это то же самое, что в Oralce "LogXptMode=fasysync" = SYNC NOAFFIRM. Если сетевая задержка низкая (реплика рядом с мастером), то сеть работает быстрее, чем fdatasync диска, то есть реплика получает журнальную запись быстрее, чем процесс мастера получит подтверждение на fdatasync в свой WAL и синхронная реплика не будет замедлять транзакции. Режим, аналогичный Maximum Availability.
Мультипликации транзакшн логов на мастере посгреса нет, это в оракле. Команд наката транзакшн логов в посгресе нет. В Oracle при ручной активации резервной базы, если не было режима Maximum Protection, я бы тоже рекомендовал проверить сохранились ли оперативные журналы primary и, по возможности, скопировать их и наложить перед активаций резервной базы, если позволяет время, так как в режиме Maximum Availability если сеть между primary и standby разорвется непосредственно перед падением primary, Availability не гарантирует отсутствие потерь транзакций - через NET_TIMEOUT=30 секунд primary подтверждает транзакции без standby и их может быть много. В PostgreSQL такого нет - транзации не подтверждаются и висят, если не прервать сессии или процессы как я описал в статье. То есть разница между Oralce и PostgreSQL есть. Общее то, что ручной накат журналов с primary/мастера на standby/реплику ни в PostgreSQL, ни в Oracle не описывается и не рекомендовался. Можно ли было бы Patroni переносить WAL с матера и проверять есть ли расхождение с репликой, думаю, это было бы сложно и породило бы более вероятные сбои. Даже вручную это чревато ошибками.
Для защиты от одновременного умирания придётся разнести команду и COMMIT:
postgres=# begin;
BEGIN
postgres=*# insert into t1 values (1) returning txid_current();
txid_current
--------------
805
(1 row)
INSERT 0 1
Cохранить полученный номер транзакции на серевере приложений (бизнес-логики) в файл или куда-нибудь.
Дальше послали COMMIT, но подтверждения не получили. Сервер приложений и/или базы данных упали. После перезапуска сервера приложений прочли номер транзакции из файла. Дальше достаточно проверить статус транзакции:
Если сервер приложений обслуживает человека, то при падении сервера приложений веб-сессия разорвётся сразу после нажатия кнопки человеком "выполнить", человек в новой сессии догадается проверить выполнился ли "выполнить" (баланс счета поменялся или по истории проводок).
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 после) он сам не уменьшает файлы, за него это вакуум делает.
если не додумывать, страшилок нет. Жирным текстом выделил фразу "Что хорошо". Это как COPY WITH FREEZE - в документации пугают нарушениями видимости, но всё просто, только надо об особенности знать.
Минус по производительности будет, если на Oracle установить Maximum Protection. Он фиксирует транзакцию, если журнальная зпись передана резервной базе (SYNC) + резервная база записала журнальную запись на диск (AFFIRM). Maximum Availability допускат "fastsync" - (SYNC NOAFFIRM). Фаст значит быстрый, его и используют. Этот режим преедачи журналов и выставляют и для Maximum Availability и для Maximum Performance. Режим передачи не зависит от режима защиты, можно стаить как угодно.
В PostgreSQL аналогично: synchronous_commit=on, это абсолютно то же самое, что в Oracle SYNC AFFIRM - работает медленно. Если установить synchronous_commit=remote_write , то это то же самое, что в Oralce "LogXptMode=fasysync" = SYNC NOAFFIRM. Если сетевая задержка низкая (реплика рядом с мастером), то сеть работает быстрее, чем fdatasync диска, то есть реплика получает журнальную запись быстрее, чем процесс мастера получит подтверждение на fdatasync в свой WAL и синхронная реплика не будет замедлять транзакции. Режим, аналогичный Maximum Availability.
Мультипликации транзакшн логов на мастере посгреса нет, это в оракле. Команд наката транзакшн логов в посгресе нет. В Oracle при ручной активации резервной базы, если не было режима Maximum Protection, я бы тоже рекомендовал проверить сохранились ли оперативные журналы primary и, по возможности, скопировать их и наложить перед активаций резервной базы, если позволяет время, так как в режиме Maximum Availability если сеть между primary и standby разорвется непосредственно перед падением primary, Availability не гарантирует отсутствие потерь транзакций - через NET_TIMEOUT=30 секунд primary подтверждает транзакции без standby и их может быть много. В PostgreSQL такого нет - транзации не подтверждаются и висят, если не прервать сессии или процессы как я описал в статье. То есть разница между Oralce и PostgreSQL есть. Общее то, что ручной накат журналов с primary/мастера на standby/реплику ни в PostgreSQL, ни в Oracle не описывается и не рекомендовался. Можно ли было бы Patroni переносить WAL с матера и проверять есть ли расхождение с репликой, думаю, это было бы сложно и породило бы более вероятные сбои. Даже вручную это чревато ошибками.
Для защиты от одновременного умирания придётся разнести команду и COMMIT:
Cохранить полученный номер транзакции на серевере приложений (бизнес-логики) в файл или куда-нибудь.
Дальше послали COMMIT, но подтверждения не получили. Сервер приложений и/или базы данных упали. После перезапуска сервера приложений прочли номер транзакции из файла. Дальше достаточно проверить статус транзакции:
Если сервер приложений обслуживает человека, то при падении сервера приложений веб-сессия разорвётся сразу после нажатия кнопки человеком "выполнить", человек в новой сессии догадается проверить выполнился ли "выполнить" (баланс счета поменялся или по истории проводок).
это, наверное, про Флант https://habr.com/ru/companies/flant/news/850452/
Тоже удивился, что за Флант и зачем
это Добби
в интернет можно найти: расходы на з/п:
2024г.: 1.85 млрд./386 чел./12 мес. = 400т.р.
2025г.: 2.82 млрд./538 чел./12 мес.= 436т.р. в месяц
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 после) он сам не уменьшает файлы, за него это вакуум делает.