У меня есть главный сервер и установка горячего резервирования с PostgreSQL 9.3, и я пытаюсь отслеживать состояние репликации в резервном режиме с помощью check_postgres инструмент и действие "hot_standby_delay". Кажется, это работает путем вычисления разницы в байтах между позицией xlog на главном и резервном серверах.
Во многих онлайн-примерах я видел предупреждения и критические пороги для этого в диапазоне <1 МБ. Точная команда, которую мы используем в Nagios:
/usr/local/bin/check_postgres.pl --action=hot_standby_delay --host=$HOSTNOTES$,$HOSTADDRESS$ --port=5432 --dbname=monitoring --dbuser=monitoring --dbpass=monitoring --warning=1000000 --critical=5000000
Это должно установить предупреждение примерно на 1 МБ и отключение примерно на 5 МБ. Однако на наших серверах мы регулярно наблюдаем скачок до высокого уровня, например:
[1417719713] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;1;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 121175880
[1417719773] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;2;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 132780968
[1417719833] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;3;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 21412936
В продолжение следующей проверки Nagios:
[1417719893] SERVICE ALERT: host;PostgreSQL: Replication Delay;OK;SOFT;4;POSTGRES_HOT_STANDBY_DELAY OK: DB "monitoring" (host:host.example.com) 0
Итак, в общем смысле кажется, что репликация работает (и действительно, выполнение обновления данных на главном сервере дает немедленные результаты в резервном).
К сожалению, этот сценарий делает мониторинг бесполезным, поскольку он вызывает ложное срабатывание много раз в день. Судя по тому, что я нашел между документацией и другими примерами использования этого, этот результат нетипичен, и большинство людей могут установить порог в 1 МБ или меньше и видеть ошибки только тогда, когда действительно есть ошибки.
Кто-нибудь знает, что я могу попробовать с конфигурацией, чтобы исправить это? В этой конкретной установке мы изменили только несколько параметров, и из них только wal_keep_segments кажется даже отдаленно связанным (и у нас это установлено на 128).
И главный, и резервный размещены в EC2 в одной и той же зоне доступности, и, похоже, между ними нет каких-либо задержек связи. Это также база данных с очень низким трафиком, поэтому я не уверен, почему дельта xlog может быть такой далекой с самого начала, если я не упускаю какой-то очень важный факт.
Проверка, возвращающая SOFT CRITICAL, не запускает уведомления, так как она не достигла max_check_attempts порог. Это не ложное срабатывание; это Nagios, работающий как задумано. Это вполне нормально (для многих сервисов, не только для вашего случая). Именно поэтому существует max_check_attempts.
В вашем случае он возвращается в норму в течение 3 минут после первоначального отрицательного результата проверки. Для некоторых служб такое время рассинхронизации приемлемо, но может не подходить для вашего варианта использования. Я недостаточно знаю о репликации Postgres, чтобы однозначно сказать, указывает ли это на основную проблему или нет.