опытный dba говорил, что постгрес не любит когда на мастер идет только пишущая нагрзука а с реплик чтение. Кажется это как-то связано с передачей статистики и некорректного построение планов на репликах из-за этого. Подскажите пожалуйста можно ли об это где-то почитать?
Не очень похожэ на правду. Я, правда, так непомню, когда там analyze запускается... Но по-моему это зависит в первую очередь от объёмов записи. И есть нюансы, что чтение страниц можэт дёрнуть полу-вакуум такой на страницэ... Разгрузив чуть-чуть реальный автовакуум... Но запись-то тожэ в среднем страницы читает, да и нагрузка с этого чтения всё равно идёт. В общем, я такого не наблюдал, и это не выглядит очень вероятным. В частности -- занимайтесь нагрузочным тэстированием, и вам будет всё равно, бывает такое или нет -- поскольку результаты покажут, справится ли ваша система с вашэй нагрузкой, и какая вам разница на весь остальной мир.
Спасибо за ответ, просто это нам говорили классные разрабы из postgresPro, а сейчас нет возможности уточнить))) Попроробую еще поискать если найду что-то поделюсь))
Плохо сочетается OLTP нагрузка на мастере и отчетное чтение с долгими (минуты и дольше, но в целом будет зависеть от того насколько интенсивная у вас запись на мастере) запросами на реплике. Для того чтобы гарантировать что долгий запрос на реплике завершится, а не отлетит due to conflict with recovery - нужно включать hot_standby_feedback. Это параметр будет передавать на мастер данные раньше какого xid'а ещё нельзя удалять. В итоге при интенсивной записи на мастере, и долгих запросах на реплике получаем постоянно откладываемый автовакуум на мастере, и как следствие bloat таблиц, и деградация производительности.
>нужно включать hot_standby_feedback. И получить все те жэ проблемы на ведущем, что и при просто долгих запросах на нём... (Этот параметр не просто так не включен по дефолту.)
Я же об этом и написал
Обсуждают сегодня