надо научиться жить :)

Наткнулся тут на тред https://www.postgresql.org/message-id/f49bb262-d246-829d-f835-3950ddac503c%40postgrespro.ru где хотят сделать более гранулированный автовакуум - чистить не по всей таблице и по конкретным страницам. Не знаю, пройдёт ли идея или нет.

вроде уже давно хотели, разве ещё не имплементировали?

вроде уже давно хотели, разве ещё не имплементировали?

были другие попытки?

были другие попытки?

да вроде это первое что приходит на ум когда думаешь о автовакууме

да и про сборщики муссора в целом много чего известно

мой вам совет, не используйте pgpool

а что лучше вместо него?

умный приклад

качественного решения для автоматического разруливания балансировки пока, увы, нет

умный приклад

кто же его напишет то...

разработчик

надо просто держать 2 persistent connection'a

один для insert/update

другой для select (без sequences)

просто я тоже был оптимистом по части pgpool

там очень много головной боли, связанной с переключением мастера

просто я тоже был оптимистом по части pgpool

О, а расскажите. Я вот не использовал, а вчера документацию полистал... и как-то мне не по себе стало. ;)

ооо...

там столько интересного и кривого

ну тогда слушайте (с)

=)

короче

логика переключения мастера базируется на неких эвентах

как только срабатывает эвент, то запускается определенный скрипт(написать надо самому)

далее еще чудеснее

скрипт для переключения запускается не через ssh, а через расширение, которое надо поставить на каждый pgsql

скрипт для переключения запускается не через ssh, а через расширение, которое надо поставить на каждый pgsql

Какое-то "удивительное" решение. ;)

ага

до сих пор думаю матом про него

там есть некий управляющий интерфейс pcp_*

это лютый ппц

а! во!

главное, если реплика(слейв) к примеру, вывалилась из пула, то ее включать только руками через pcp_

я всё это разворачивал с centos

и пакет дико глючил

особенно по части балансировки

пришлось сливать с сайта разработчика

текс...

чёго там еще веселого

а во!

авторизация!

вам придётся делать 2х этапную авторизацию... буквально

т.е. длогин/пароль в базе

главное, если реплика(слейв) к примеру, вывалилась из пула, то ее включать только руками через pcp_

Нет, ну в этом ещё может быть смысл... наверное (а то автоматически можно было бы "вставить" в pool отставшую и т.п. реплику).

и логин/пароль в файле для pgpool, зашифрованный по md5

Нет, ну в этом ещё может быть смысл... наверное (а то автоматически можно было бы "вставить" в pool отставшую и т.п. реплику).

на это там есть возможность автоматизировать скриптом создание реплики

но оно тоже работает через пень колоду

реплика перезаливается, а в кластер не влетает

т.е. вконец скрипта надо добавлять pcp_

ща вспомню, как там оно зовётся...

pcp_attach_node

во...

Нда. А какое у нас тогда нормальное решение для load balancing, интересно...

никакого

погодите

это еще не все

т.к. pgpool - это по сути кусок pgsql'я, то он унаследовал все прелести prefork модели работы с коннектами!

А это значит следующее...

У меня было 2 ПГпула, настроенных на 3 сервера

1 мастер + 2 реплики

надо было организовать вачдог, чтоб при падении 1 пула, 2й поднимал флпаг и далее по списку.

Вачдог в нём работает шикарно

что есть то есть

адрес перескакивает на ура

но вот незадача

ERROR: S client not available

у меня в настройках сервера было 300 коннектов

но когда я подключаю два ПГпула, их получается 600!

а всё потому, что он использует всё тот же хвалёный префорк

кстати, коннекты он не отдаёт

Решил я эту задачу просто

закостылил pgbouncer

получилось так: pgpool —- pgbouncer —- pgsql

вобщем резюме. 1. Переключение реплик - надо костылить много 2. Балансировка - да, но многие жалуются на потерю производительности вплоть до 20% 3. Вачдог - да, но не без костылей с коннектами

Я конечно извиняюсь, но не могли бы Вы, Михаил, писать в сообщениях хотя бы целые предложения? Про абзацы я не говорю. Спасибо

Жжесть. ;( А мне сходу не понравилось то, что даже в release notes отмечается относительно много критических ошибок (в каждом release!). И потом, похоже, pgpool навязывает политику — т.е. делай такую архитектуру, как мы задумали, и без вариантов.

Я попытаюсь. Пожалуйста.

Ну он, да, странный какойто

Сейчас я остановился на связке haproxy - pgbouncer -patroni - pgsql

если интересно, расскажу =)

Ну он, да, странный какойто

Спасибо! Не зря он мне с виду не понравился, короче. ;)

Взаимно :)

если интересно, расскажу =)

Ну это я примерно представляю...

а, там еще vrrp добавили для переноса кластерного ip

По моему ребята из постгреспро тоже както не лестно о пгпул отзывались

не помню ток где встречал =)

меня вот щас интересует больше идея PgSQL over HDP

но там с вакуумом те же грабли :)

По моему ребята из постгреспро тоже както не лестно о пгпул отзывались

Да много кто, похоже, нелестно отзывается. :)

Я конечно извиняюсь, но не могли бы Вы, Михаил, писать в сообщениях хотя бы целые предложения? Про абзацы я не говорю. Спасибо

Ты не извиняйся. Человек просто не уважает остальных 2K людей в этом чате.

@uspen2018 вот вас я теперь отдельной строкой не уважаю

:)

Сейчас я остановился на связке haproxy - pgbouncer -patroni - pgsql

Ок, спс, гляну в эту сторону

Привет! Кто-то настраивал аутентификацию через RADIUS? Постгрес может передавать только хешированные пароли? Он может использовать метод PAP с радиусом?

@kabil888 будет жить. Поприветствуем!

если интересно, расскажу =)

интернсно

select sku_id from shop_feature_brand_sku where feature_value_code = 'xiaomi' intersect select sku_id from shop_feature_cores_sku where feature_value_code = 2 intersect select sku_id from shop_feature_ram_sku where feature_value_code = 4096 Как можно оптимизировать этот запрос? индексы вешать я так понимаю не вариант, cardinality будет низкий. EXPLAIN: http://tatiyants.com/pev/#/plans/plan_1533906548722