Налаштування Redis Sentinel для високої доступності

Ми часто стикаємося з ситуацією: 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 кроків

1. Встановіть Redis на всі три сервери (однакова версія, наприклад 7.2).
2. Налаштуйте майстер — вкажіть паролі, ліміт пам'яті, увімкніть AOF.
3. Налаштуйте репліки — додайте параметр replicaof <master-ip> 6379.
4. Налаштуйте Sentinel — створіть sentinel.conf з налаштуваннями монітора, пароля та таймаутів.
5. Запустіть Sentinel на всіх серверах командою redis-sentinel /etc/redis/sentinel.conf.
6. Перевірте стан — виконайте 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 без ризику?

Ми рекомендуємо перед запуском у продакшен провести симуляцію:

1. Зупиніть майстра: systemctl stop redis.
2. Спостерігайте логи Sentinel — через 5–15 секунд повинен початися failover.
3. Перевірте нового майстра: SENTINEL master mymaster — поле ip зміниться.
4. Запустіть старого майстра назад: systemctl start redis — він автоматично стане реплікою нового майстра.

Типові помилки при тестуванні:

• Не перевірені паролі — failover може не спрацювати через auth-pass.
• Завеликий down-after-milliseconds — затримка до 30 секунд.
• Відсутній notification-script — ви не дізнаєтеся про зміну майстра.

Порівняння: Sentinel vs. Redis Cluster

Для 90% проектів з обсягом даних до 64 ГБ Sentinel — оптимальний вибір.

Порівняння часу простою

За рахунок автоматизації ви економите десятки годин на рік та виключаєте людський фактор.

Що входить у налаштування під ключ

Ми надаємо:

• Конфігурацію 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) у фаєрволі.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.