Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Як Sentinel забезпечує відмовостійкість Redis?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)Redis Sentinel забезпечує відмовостійкість через постійний моніторинг вузлів (`PING`), а коли master не відповідає, спершу позначає його як "суб'єктивно мертвий" (SDOWN); лише коли кілька Sentinel погоджуються, що вузол справді недоступний, він стає "об'єктивно мертвим" (ODOWN), і Sentinels обирають лідера, який підвищує одну з реплік до нового master. **Ключове:** після фейловеру Sentinel розсилає клієнтам сповіщення через Pub/Sub (`+switch-master`), а старий master, коли повертається, автоматично стає реплікою нового - усе відбувається без ручного втручання, хоч дані, що не встигли потрапити на репліки через асинхронну реплікацію, можуть бути втрачені.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**Redis Sentinel** забезпечує відмовостійкість за рахунок постійного моніторингу вузлів Redis і автоматичного вибору нового master при збої. Ось як це працює покроково: ### 1. Моніторинг Кожен Sentinel відстежує всі Redis-вузли в системі: - регулярно надсилає піги (`PING`) master і його репліками; - якщо master не відповідає визначений час (`down-after-milliseconds`), Sentinel позначає його як **subjectively down (SDOWN)** - *"на мою думку, він мертвий"*. ### 2. Кворум (підтвердження збою) Один Sentinel не може сам оголосити master "упалим". Щоб уникнути хибних спрацьовувань, кілька Sentinels мають **погодитися**, що вузол справді недоступний. Коли згоду досягнуто, master позначається як **objectively down (ODOWN)** - *"об'єктивно мертвий"*. ### 3. Автоматичний фейловер Коли master визнано ODOWN: 1. Sentinels обирають **нового "лідера" серед себе** (через Raft-подібний процес голосування). 2. Лідер обирає одну з реплік master і **підвищує її до нового master** за допомогою команди `SLAVEOF NO ONE`. 3. Решта реплік перенастроюються реплікуватися вже від цього нового master. ### 4. Сповіщення клієнтів Після фейловеру Sentinel: - оновлює конфігурацію, - розсилає сповіщення клієнтам через Pub/Sub-канали (`+switch-master`), - клієнти, що підтримують Sentinel, автоматично підключаються до нового master. ### 5. Відновлення попереднього master Якщо старий master повертається: - він **автоматично стає реплікою** нового master, - система лишається в стійкому стані без ручного втручання. ### Підсумок: Redis Sentinel забезпечує відмовостійкість через три механізми: 1. **Моніторинг доступності** всіх вузлів. 2. **Голосування Sentinels** для підтвердження збою. 3. **Автоматичний фейловер** і оновлення конфігурації клієнтів. Це дозволяє системі Redis **самостійно відновлюватися** після падіння master без втрати даних (крім тих, що не встигли потрапити на репліки через асинхронну реплікацію).Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.