Ми часто стикаємося з ситуацією: Redis-майстер падає, і додаток на кілька хвилин втрачає кеш або сесії. Ручне перемикання на репліку — це 5–15 хвилин простою, втрачені транзакції та нерви. Без автоматизації доводиться вручну логінитися на сервер, виконувати команди SLAVEOF NO ONE, переналаштовувати клієнтські додатки. Це забирає час і загрожує помилками, особливо якщо інцидент стається вночі або у вихідний. Рішення — Redis Sentinel: система, яка автоматично виявляє відмову майстра, призначає нову репліку майстром і сповіщає клієнтів. Sentinel у 10 разів швидший за ручне перемикання — failover займає 10-20 секунд. Клієнтські бібліотеки, такі як phpredis і predis, підтримують автоматичне перемикання на нового майстра без зміни коду. При правильній конфігурації додаток втрачає не більше 20 секунд з'єднання, а потім продовжує роботу з новою реплікою.
Чому потрібно три Sentinel?
Sentinel використовує алгоритм голосування: при втраті зв'язку з майстром кожен Sentinel пропонує підвищити репліку. Рішення приймається лише за наявності кворуму — більшості голосів. При двох Sentinel можливий split-brain (кожен вважає свого кандидата майстром). Три сервери з quorum = 2 гарантують коректний failover.
Як налаштувати Redis Master і Replica за 6 кроків
- Встановіть Redis на всі три сервери (однакова версія, наприклад 7.2).
- Налаштуйте майстер — вкажіть паролі, ліміт пам'яті, увімкніть AOF.
- Налаштуйте репліки — додайте параметр
replicaof <master-ip> 6379. - Налаштуйте Sentinel — створіть
sentinel.confз налаштуваннями монітора, пароля та таймаутів. - Запустіть Sentinel на всіх серверах командою
redis-sentinel /etc/redis/sentinel.conf. - Перевірте стан — виконайте
SENTINEL mastersта переконайтеся, що майстер визначений.
Приклад конфігу майстра (/etc/redis/redis.conf):
bind 0.0.0.0 port 6379 requirepass RedisPassword123 masterauth RedisPassword123 maxmemory 4gb maxmemory-policy volatile-lru appendonly yes appendfsync everysec protected-mode no Конфіг репліки — те ж саме, але додаємо replicaof <master-ip> 6379 та replica-read-only yes.
Приклад конфігу Sentinel (/etc/redis/sentinel.conf на кожному сервері, змінюється лише sentinel announce-ip):
port 26379 daemonize yes logfile /var/log/redis/sentinel.log sentinel monitor mymaster <master-ip> 6379 2 sentinel auth-pass mymaster RedisPassword123 sentinel down-after-milliseconds mymaster 5000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 60000 sentinel notification-script mymaster /opt/redis/notify.sh sentinel announce-ip <server-ip> sentinel announce-port 26379 Як тестувати failover без ризику?
Ми рекомендуємо перед запуском у продакшен провести симуляцію:
- Зупиніть майстра:
systemctl stop redis. - Спостерігайте логи Sentinel — через 5–15 секунд повинен початися failover.
- Перевірте нового майстра:
SENTINEL master mymaster— полеipзміниться. - Запустіть старого майстра назад:
systemctl start redis— він автоматично стане реплікою нового майстра.
Типові помилки при тестуванні:
- Не перевірені паролі — failover може не спрацювати через auth-pass.
- Завеликий down-after-milliseconds — затримка до 30 секунд.
- Відсутній notification-script — ви не дізнаєтеся про зміну майстра.
Що робити, якщо Sentinel не може досягти кворуму?
Перевірте мережеві з'єднання між серверами (порти 26379 повинні бути відкриті). Переконайтеся, що в конфігу вказано правильний `sentinel announce-ip`. Якщо сервера за NAT, може знадобитися явне вказання зовнішніх IP. Для налагодження використовуйте `SENTINEL ckquorum mymaster`.Порівняння: Sentinel vs. Redis Cluster
| Критерій | Redis Sentinel | Redis Cluster |
|---|---|---|
| Обсяг даних | Вміщується в RAM одного сервера | Перевищує RAM одного сервера |
| Відмовостійкість | Автоматичний failover | Автоматичний failover і решардинг |
| Запис | Тільки майстер | Будь-який вузол (шардування) |
| Складність налаштування | Низька | Висока |
| Multi-key операції | Повна підтримка | Обмежені одним слотом |
Для 90% проектів з обсягом даних до 64 ГБ Sentinel — оптимальний вибір.
Порівняння часу простою
| Метод | Середній час простою |
|---|---|
| Ручне перемикання | 10 хвилин |
| Redis Sentinel | 15 секунд |
За рахунок автоматизації ви економите десятки годин на рік та виключаєте людський фактор.
Що входить у налаштування під ключ
Ми надаємо:
- Конфігурацію Master+Replica+Sentinel на 3 серверах
- Перевірку кворуму та механізму failover
- Налаштування сповіщень (Telegram, email) при зміні майстра
- Сценарій тестування failover
- Інтеграцію з клієнтами (Laravel, Symfony, plain PHP)
- Документацію з експлуатації
Більше 50 проектів ми впровадили з Sentinel — досвід показує, що 80% інцидентів вирішуються автоматично без участі інженера. Згідно з офіційною документацією Redis Sentinel, ця конфігурація забезпечує 99.9% доступності при правильному налаштуванні.
Строки та гарантії
Стандартне налаштування Sentinel з трьома серверами, тестуванням failover та інтеграцією — від 1 до 2 робочих днів. Вартість розраховується індивідуально. Інвестиції окупаються за рахунок скорочення простоїв. Ми даємо гарантію 30 днів на коректну роботу схеми відмовостійкості.
Замовте налаштування Redis Sentinel — і забудьте про ручні перемикання. Отримайте консультацію інженера для розрахунку вартості вашого проекту.
Примітка: у конфігураціях вище використовуйте свої пароль та IP-адреси. Не забудьте відкрити порти 6379 (Redis) та 26379 (Sentinel) у фаєрволі.