эм, минутку

всё воркает - я в вэб-версии на пека сижу, пока не закинул с телефона в избранное в вэб-версии не появилась эта группа, сейчас проверил - закинул с пека\телефона в группу - всё доступно для скачивания и использования, а то что нельзя ссылку отправить на файл\сообщение - особенность облака такая

она висит. а коммунигейт - порождение легендарных сссровских юниксоидов из 90ых

есть кластер patroni с etcd в качестве распределенного хранилища и keepalived для virtual IP.
По какой причине, может отваливаться коннект к БД, при падении одной ноды etcd, нода не лидер.

а как же Mdaemon (:

а почему бы ему не  отваливаться? в большинстве решений так называемых HA соединения отваливаются при переключении.
там есть прокси в комплекте?

и это обычно не мешает всему работать

есть
ну насколько я понимаю, прокси отправляет запросы мастер ноде постгреса.
etcd — хранит состояние кластера и каким образом отвал одной ("slave") ноды с etcd и haproxy должен приводить к разрыву коннекта не совсем понимаю. В моем понимание было, что в поддержке коннекта используется то, что текущий момент "master". нет?

Слушай, ничего в этом ПАТРОНЕ твоем не понимаю, но посуди сам:
есть virtual ip - просто фокус на уровне arp.
Вот есть два сервера, на одном один набор открытых соединений, на другом - другой.
Если сервер издох, как второй узнает какие там были установлены соединения?
А вот полезные данные они вполне могут разделять между собой.

обычно приложение просто так написано, что при разрыве соединения переподключается.

а где упоминается haproxy ? не было в исходном сообщении

диалог поддержать не смогу, плаваю в теме, но на какую тему гуглить нужно — понял.
неправильно видимо понимал, логику работы. Я думал, virtual ip висит на одной из нод, вес которой в конфиге указан максимальным (мастер). Ну и соответственно все коннекты к этому virtual ip, отправляются в соответствии с настройками haproxy (в моем случае на мастер ноду постгресса)

да, но нет.
базу колцентр использует. Его переподключение не очень быстрое занятие.
Был уверен, что все что не мастер можно безбоязненно трогать, сервер колцентра не заметит изменение в состоянии СУБД

мне кажется, было бы разумно даже в  haproxy сделать переподключение, потому что в sql есть транзакции и разные состояния. Нельзя прозрачно кинуть подключение в другое место посередине  запроса.

так в том то и дело, что haproxy настроен на отправку запросов на одну ноду кластера patroni, ту которая в состоянии leader
т.е. при отвале одной ноды, ничего не должно мешать работе как мне казалось.
Предполагаю, что неправильно понимаю механизм работы vip. Думал, что это "плавающий" по нодам адрес, но похоже он работает одновременно на всех нодах.

>When a database node fails, the database connections that have been opened on that node will also fail.

https://severalnines.com/resources/database-management-tutorials/postgresql-load-balancing-haproxy

это про другое.
тут балансировка между нодами postgress.
в моем случае все ноды постгрес были живы, отваливалась нода с etcd/haproxy на борту

Смотрел вебинар Zabbix на тему Zabbix + Prometheus. Выкладываю для вас презентацию с него. Там есть полезные примеры, как самому настраивать шаблоны и собирать метрики с промовских экспортеров, в том числе и с автообнаружением. Благодаря http агентам Zabbix это не представляет большой сложности.

Вообще, странно, что Zabbix не делает записи вебинаров и не выкладывает на yuotube вместе с презентациями. Мне кажется, это только повысит охват аудитории. Записываться на вебинар по конкретному времени, да еще и утром, не очень удобно.

Всем привет ! На одном из вебинаров , я поднимал вопрос о записях , но воз и ныне там (

про это. базовая проблема с sql, которую и  не пытаются решить, потому что сложна