#кворум — Public Fediverse posts

Автообновления Linux: почему сервер моргает по утрам, а кластер теряет кворум

Ubuntu Server и Debian ставят security-обновления сами, по умолчанию — это не настройка, которую кто-то включил, а поведение из коробки. У механизма два типичных следствия, которые админ месяцами не может опознать. Одиночный сервер «моргает» каждое утро в районе 06:xx на 10–30 секунд: сервис остановлен и тут же запущен, виновного в журнале будто нет, и даунтайм списывают то на сеть, то на GC. Кластер из трёх–пяти узлов, который спокойно переживает падение одного узла, в какой-то момент роняет себя сам: обновление с перезапуском прилетело на все узлы в одно утро — кворума не осталось. Источник у обоих один: таймеры автообновлений с узким окном после шести утра плюс needrestart , который перезапускает не только обновлённый сервис, но и всё, что слинковано с обновившейся системной библиотекой ( libssl3 , libc6 , zlib1g ). Разберём, как подтвердить диагноз за две минуты и как развести узлы во времени — от drop-in к таймеру до координации через Ansible и PodDisruptionBudget.

https://habr.com/ru/articles/1051978/

#unattendedupgrades #dnfautomatic #needrestart #systemd #OnCalendar #автообновления #Linux #кластер #кворум #отказоустойчивость

Мониторинг SQL Server Always On в Zabbix

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта. У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.

https://habr.com/ru/companies/cloud4y/articles/1017578/

#SQL_Server #Always_On #Zabbix #мониторинг #DMV #WSFC #кворум #failover #DBA