Настройка PostgreSQL под Linux

Да, это конечно же важно, но я в первую очередь старался описать стандартные настройки, которые можно/нужно делать для человека, который не особо сильно разбирается в PostgreSQL. А если человек не особо разбирается, то и логи он читать вряд ли будет.

К сожалению, мы все таки не можем так рисковать. Дело в том, что многие наши клиенты вообще не используют асинхронную реплику для резервирования. И в случае падения базы, можно считать, что целый день очень много людей работали зря. По этой же причине на всякий случай не отключаем и full_page_writes.

Но если есть сервер с асинхронной репликой с такими же характеристиками как и основной (что получается в 2 раза дороже), то я думаю можно для ускорения и nobarrier поставить, и full_page_writes отключить. А если уж совсем рисковать, то вообще вырубить fsync = off.

Много раз так делал - никаких проблем не возникало. Именно так переключались между CentOS 8 и CentOS 7 для тестирования. С физической репликой не доводилось настраивать между совсем разными ОС, но если честно не понимаю почему должны быть проблемы.

насколько помню, разница в винде и линуксе. Между линуксами не должно быть проблем. Это изза особенностей реализации сетевого стэка, который не захотели пилить под винду.

Кстати, вот как раз недавно как раз возникла проблема. Правда не при переподключении диска, а при переключении на реплику (что в принципе тоже самое) на другой версии ОС (c CentOS 7 на CentOS 8).

Проблема может возникнуть со индексами по строкам, если они содержат специфические символы. Дело в том, что PostgreSQL сравнивает строки используя общие библиотеки из ОС. А в разных ОС могут быть разные реализации сравнения хитрых символов (понятно, что цифры и латинские буквы сравниваются одинаково). В итоге такие индексы становятся невалидными (и самое печальное, что это обнаруживается только через некоторое время). Лечится простой переиндексацией таких индексов. Так что это надо иметь ввиду при переезде между ОС. Планируется, что в следующих версиях PostgreSQL это изменят.

Цель статьи в том, чтобы показать какие настройки мы устанавливаем для своих приложений. Тем самым я хотел показать, что в настройках PostgreSQL нет ничего сложного. И любой новичок, может установить просто параметры как в статье, глубоко не вникая в них. При этом все будет уже работать достаточно эффективно.

Если нужно почитать более подробно про любые параметры, то они хорошо описаны в официальной документации (или на русском языке в postgres pro).

Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.

А можете уточнить, о каком именно кэше идет речь ? Shared buffers общий для всех процессов. И про какие лимиты памяти на сессии идет речь ? Work_mem - это лимит даже не на запрос, а одну операцию.

Тут важны детали. Очень странный критерий - банковская система.

Да, это не критерий, конечно же. Тут скорее это критично для операций с распределенными транзакциями. Банковская система - это просто один из наиболее распространенных примеров, когда будет очень плохо, если в одной системе деньги списались, а в другой - нет.

Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.

Проблема в том, что в Postgres похоже есть явная утечка памяти (во всяком случае при работе с временными таблицами и большом количестве разных сложных запросов). То есть долго существующие соединения при такой схеме постепенно подъедают память, пока не сожрут ее полностью. Это очень хорошо на графиках мониторинга видно (выключаешь перестарт соединений, линия потребления начинает постепенно уходить вниз до нуля, после чего здравствуй своп / oom killer и сервер БД ложится). Видимо поэтому существуют мифы, что Postgres не тянет больше 1к одновременных соединений и вообще без пулинга из очень малого количества соединений не может эффективно работать.

Ну и надо сказать, что при выборе соединений на перестарт используется сложная система скоринга (пытающаяся определить "зажравшиеся" соединения) и один из параметров это время жизни соединения, который все же старается не перестартовывать недолго существующие соединения, чтобы эффективно утилизировать использование их кэшей.