Как проверить, сколько слейвов подключено

Проверка количества подключённых слейвов — критически важная задача для администрирования распределённых систем, особенно в контексте баз данных и серверной инфраструктуры. В зависимости от используемой технологии (например, MySQL, Redis, PostgreSQL с репликацией или кастомные решения) применяются разные методы мониторинга. Главное — использовать встроенные команды или инструменты управления, которые предоставляют актуальную информацию о состоянии репликации.

Как проверить количество слейвов в MySQL

В архитектуре MySQL репликация строится по принципу master-slave, где мастер принимает все изменения, а слейвы получают их по протоколу бинарных логов. Чтобы определить, сколько реплик в данный момент подключено к мастеру, необходимо выполнить соответствующие SQL-запросы на стороне главного сервера.
Наиболее прямой способ — команда `SHOW SLAVE HOSTS`. Она выводит список всех рабочих хостов, зарегистрированных как слейвы. Однако важно понимать, что эта команда покажет только те серверы, которые были запущены с параметром `—report-host`, передающим своё имя мастеру при подключении.
Пример использования:

1. Подключитесь к MySQL-мастеру через клиент: mysql -u root -p.
2. Выполните: SHOW SLAVE HOSTS;.
3. Проанализируйте результат: столбцы Server_id, Host, Port, Master_id.

Если команда ничего не возвращает, это может означать одно из трёх: слейвы не подключены, не задан --report-host, или используется GTID-репликация без явной регистрации.
Альтернативный подход — анализ таблицы `replication_connection_status` в schema `performance_schema`. Здесь можно получить более детальную информацию о текущем состоянии подключений:
«`sql
SELECT CHANNEL_NAME, SERVICE_STATE
FROM performance_schema.replication_connection_status;
«`
Кроме того, полезно проверять `replication_applier_status_by_worker`, чтобы убедиться, что события не только получены, но и применены.

Шаги для диагностики в MySQL

• Убедитесь, что на слейвах установлен параметр report_host='имя_хоста' в my.cnf.
• Проверьте, что переменная report_port указана, если используется нестандартный порт.
• На мастере включите log_slave_updates, если нужна многоуровневая репликация.
• Используйте SHOW PROCESSLIST для поиска потоков типа Slave_IO — они могут указывать на активные соединения.

Определение числа слейвов в Redis

Redis традиционно использует простую модель master-slave репликации. Каждый слейв подключается к мастеру и синхронизирует данные. Проверка количества подключённых слейвов — одна из стандартных операций мониторинга.
Основной способ — команда `INFO REPLICATION`. Она возвращает подробный отчёт о репликационной топологии. На мастере в разделе connected_slaves будет указано точное число активных реплик.
Пример вывода:

# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.10,port=6379,state=online,offset=123456,lag=1
slave1:ip=192.168.1.11,port=6379,state=online,offset=123450,lag=2
master_replid:8a7b6c5d4e3f2...
master_repl_offset:123456

Здесь строка connected_slaves:2 говорит, что два слейва подключены. Далее идёт детализация по каждому: IP, порт, состояние, отставание (lag).
Если вы видите connected_slaves:0, но ожидаете подключения, стоит проверить:

• Доступность порта 6379 на мастере (через firewall).
• Правильность настройки slaveof на стороне реплики (в redis.conf или через команду).
• Наличие ошибок в логах Redis на обеих сторонах.

Автоматическая проверка в Redis

Для автоматизации можно написать скрипт на Bash или Python, который будет парсить вывод `INFO REPLICATION`:
«`bash
redis-cli INFO REPLICATION | grep connected_slaves
«`
Или через Python с использованием библиотеки redis-py:
«`python
import redis
r = redis.Redis(host=’localhost’, port=6379, db=0)
info = r.info(‘replication’)
print(f»Подключено слейвов: {info[‘connected_slaves’]}»)
«`

Репликация в PostgreSQL: как отслеживать подключение реплик

PostgreSQL использует механизм streaming replication, при котором слейвы (в терминологии PG — standby-серверы) подключаются к мастеру (primary) и получают WAL-логи в реальном времени. Количество подключённых реплик можно определить несколькими способами.
Основной запрос — к представлению `pg_stat_replication`:
«`sql
SELECT client_addr, application_name, state, sync_state FROM pg_stat_replication;
«`
Он покажет всех активных подключённых реплик: их IP-адреса, имена приложений (часто совпадают с именем слейва), состояние (streaming, catchup) и тип синхронизации (async/sync).
Если запрос возвращает пустой результат, значит, ни один слейв не подключён. Возможные причины:

• Сервис на слейве не запущен.
• Ошибка в файле recovery.conf или postgresql.auto.conf (в версиях 12+).
• Заблокирован порт 5432 или отказано в доступе через pg_hba.conf.

Важно, чтобы в `pg_hba.conf` на мастере было разрешено подключение от IP-адресов реплик:
«`
host replication replicator 192.168.1.10/32 md5
«`
Здесь `replicator` — пользователь с правами REPLICATION.

Мониторинг через системные таблицы

Дополнительно можно использовать:

• `pg_stat_wal_receiver` — на стороне слейва, показывает статус приёмника WAL.
• `pg_current_wal_lsn()` и `pg_last_wal_receive_lsn()` — для сравнения позиций и вычисления отставания.
• Логи PostgreSQL: ключевые строки вроде started streaming WAL from primary подтверждают успешное подключение.

Проверка подключения на сетевом уровне

Если стандартные команды не дают результата, стоит перейти на уровень сети. Часто проблема не в СУБД, а в сетевой доступности или firewall.
Первый шаг — проверить, слушает ли мастер нужный порт. Используйте `netstat` или `ss`:
«`bash
ss -tulnp | grep :3306 # для MySQL
ss -tulnp | grep :6379 # для Redis
ss -tulnp | grep :5432 # для PostgreSQL
«`
Если порт не слушается — проблема в запуске сервиса.
Далее — проверка активных подключений. Например, для MySQL:
«`bash
ss -tnp | grep :3306 | grep ESTAB
«`
Каждое установленное соединение (ESTAB) от слейва будет отображаться здесь. Можно дополнительно отфильтровать по IP:
«`bash
ss -tn src 192.168.1.10 dst 192.168.1.1:3306
«`
Альтернатива — `lsof`:
«`bash
lsof -i :3306 | grep ESTABLISHED
«`

Проверка через telnet или nc

Иногда достаточно проверить доступность порта с хоста слейва:
«`bash
telnet master-host 3306
«`
Если соединение не устанавливается, возможны следующие причины:

• Фаервол блокирует порт (iptables, ufw, cloud security groups).
• Сервер не привязан к внешнему интерфейсу (bind-address = 127.0.0.1 вместо 0.0.0.0).
• DNS-проблемы: хост не разрешается по имени.

Инструменты мониторинга и автоматизация контроля

Ручные проверки хороши для разового анализа, но в продакшене необходима автоматизация. Современные системы мониторинга позволяют отслеживать количество слейвов в реальном времени и отправлять алерты при отклонениях.
Популярные решения:

• Zabbix — позволяет создавать пользовательские шаблоны для MySQL, Redis, PostgreSQL с триггерами на изменение числа реплик.
• Prometheus + Grafana — сбор метрик через экспортеры (mysqld_exporter, redis_exporter, postgres_exporter). Например, метрика redis_connected_slaves сразу покажет число подключений.
• Nagios / Icinga — проверки через плагины check_mysql_replication, check_redis.

Пример метрики в Prometheus:
«`
# HELP redis_connected_slaves Number of connected replicas
# TYPE redis_connected_slaves gauge
redis_connected_slaves{instance=»redis-master:6379″} 2
«`
На основе этой метрики можно построить дашборд в Grafana и настроить алерт: «Если количество слейвов < 1 в течение 2 минут — уведомить команду».

Самописные скрипты для регулярной проверки

Если вы не используете полноценную систему мониторинга, можно написать простой cron-скрипт:
«`bash
#!/bin/bash
SLAVES=$(redis-cli INFO REPLICATION | grep -oP ‘connected_slaves:Kd+’)
if [ «$SLAVES» -lt 1 ]; then
echo «ALERT: No slaves connected to Redis master» | mail -s «Replication Alert» admin@company.com
fi
«`
Такой скрипт можно запускать каждые 5 минут через cron.

Типичные ошибки и как их избежать

При диагностике подключения слейвов администраторы часто сталкиваются с типовыми проблемами. Ниже — частые ошибки и пути их решения.

• SHOW SLAVE HOSTS возвращает пустой результат — чаще всего из-за отсутствия --report-host на слейве. Решение: добавить параметр в my.cnf и перезапустить MySQL.
• Слейв подключён, но не получает данные — проверьте, включена ли репликация (START SLAVE;) и нет ли ошибок в SHOW REPLICA STATUSG (например, mismatch UUID).
• Redis показывает 0 слейвов, но подключение есть — возможно, используется TLS/SSL, и клиент не проходит аутентификацию. Проверьте сертификаты и настройки шифрования.
• PostgreSQL: ошибка FATAL: no pg_hba.conf entry — добавьте строку в pg_hba.conf и выполните SELECT pg_reload_conf();.

Экспертное мнение

Регулярный контроль числа подключённых реплик — фундамент надёжности системы. Не стоит полагаться только на единичные проверки. Лучшая практика — комплексный подход: использование встроенных команд СУБД, сетевой диагностики и систем мониторинга.
Ключевые принципы:

• Всегда имейте как минимум одну работающую реплику.
• Мониторьте не только факт подключения, но и отставание (lag).
• Регулярно тестируйте failover — убедитесь, что слейв может стать мастером.
• Используйте единые имена и теги для слейвов — это упрощает диагностику.

В современных системах репликация — не просто резервирование, а основа масштабирования чтения, географического распределения и отказоустойчивости. Пренебрежение её контролем ведёт к рискам потери данных и простоя сервиса.

Вопросы и ответы

Заключение

Проверка количества подключённых слейвов — обязательная процедура для обеспечения отказоустойчивости и целостности данных. Каждая СУБД предоставляет свои инструменты: от `SHOW SLAVE HOSTS` в MySQL до `INFO REPLICATION` в Redis и `pg_stat_replication` в PostgreSQL. Ключевое — не просто зафиксировать число, а понимать состояние каждой реплики: подключена ли она, синхронизируется ли, есть ли отставание.

• Используйте встроенные команды СУБД для получения точных данных о репликах.
• Контролируйте не только подключение, но и отставание (lag) и статус синхронизации.
• Настройте систему мониторинга для непрерывного наблюдения и оповещения.
• Проверяйте сетевую доступность и настройки безопасности (firewall, pg_hba.conf).
• Регулярно тестируйте сценарии отказа, чтобы убедиться в готовности реплик.