Устранение распространенных ошибок переключения и подключения в кластерах PostgreSQL HA

Кластеры PostgreSQL высокой доступности (HA) выходят из строя двумя разными способами. Иногда ломается само переключение базы данных: не повышается реплика, два узла не могут договориться о первичном узле, или новый первичный узел не может принимать записи. В других случаях база данных в порядке, но приложение все равно не может подключиться из-за пулера, DNS-записи, виртуального IP-адреса, правила брандмауэра или цикла повторных попыток клиента, который не следовал за повышением.

Когда вы находитесь в инциденте, быстро разделите эти уровни. Сначала спросите: есть ли ровно один доступный для записи первичный узел? Затем спросите: может ли пулер до него добраться? Затем спросите: может ли приложение добраться до пулера или конечной точки сервиса? Такой порядок предотвращает много потраченного впустую времени на просмотр журналов приложений, в то время как менеджер кластера все еще застрял на выборах лидера.

Понимание основ PostgreSQL HA

Прежде чем углубляться в устранение неполадок, важно кратко напомнить основные компоненты кластера PostgreSQL HA:

Архитектура Первичный/Реплика: Первичная база данных обрабатывает все операции записи, в то время как одна или несколько реплик асинхронно или синхронно получают изменения через потоковую репликацию. Реплики доступны только для чтения, но служат кандидатами на повышение во время переключения.
Менеджер переключения: Инструменты, такие как Patroni, pg_auto_failover или Corosync/Pacemaker, отслеживают работоспособность первичного узла, обнаруживают сбои, выбирают новый первичный узел из доступных реплик и управляют процессом повышения. Они также обрабатывают перенастройку других реплик для следования за новым первичным узлом.
Пул соединений: Приложения часто подключаются к пулеру соединений PostgreSQL (например, PgBouncer, Odyssey), а не напрямую к базе данных. Затем пулер направляет запросы к текущему первичному узлу, обеспечивая мультиплексирование соединений, балансировку нагрузки и, возможно, абстрагируя фактический сетевой адрес первичного узла от приложений. Эта абстракция имеет решающее значение во время переключения.

Распространенные проблемы переключения и подключения и их решения

1. Сбои пула соединений во время переключения

Одна из самых частых проблем после переключения — невозможность приложений переподключиться к новому повышенному первичному узлу, несмотря на то, что сама база данных работает. Это часто указывает на проблемы с пулером соединений или кэшированием на стороне клиента.

Симптомы проблемы:

Приложения сообщают об ошибках подключения к базе данных (FATAL: database "mydb" does not exist, connection refused, server closed the connection unexpectedly).
Существующие соединения через пулер кажутся зависшими или пытаются подключиться к IP-адресу старого первичного узла.
Новые соединения также терпят неудачу, даже после завершения переключения.

Основные причины:

Устаревшие соединения в пулере: Пулер соединений может удерживать открытые соединения со старым первичным узлом и пытаться повторно использовать их, что приводит к ошибкам, когда старый первичный узел недоступен или теперь является репликой.
Неправильная конфигурация пулера: Пулер может быть не настроен на правильное обнаружение и переключение на новый первичный узел, или его server_reset_query может отсутствовать или быть неверным.
Кэширование DNS: Если ваши приложения или пулер используют DNS-запись для разрешения адреса первичного узла, устаревшие записи в кэше DNS (локально или на уровне DNS-резолвера) могут заставить их продолжать попытки подключиться к старому IP-адресу.
Отсутствие логики повторных попыток на стороне клиента: Приложения могут быть не построены с надежными механизмами повторных попыток для обработки временных проблем с подключением во время переключения.

Шаги по отладке:

Проверьте статус пулера: Получите доступ к консоли вашего пулера (например, psql -p 6432 pgbouncer -U pgbouncer) и проверьте вывод SHOW SERVERS, SHOW CLIENTS, SHOW DATABASES, чтобы увидеть, знает ли он о новом первичном узле и есть ли у него активные соединения с правильным адресом.
Проверьте сетевое подключение: С хоста пулера выполните ping и telnet к порту PostgreSQL нового первичного узла (telnet new_primary_ip 5432).
Проверьте журналы пулера: Просмотрите журналы пулера на наличие сообщений об ошибках, связанных с подключением к базе данных или попытками разрешения имен хостов.
Проверьте разрешение DNS: Используйте dig или nslookup на хосте пулера, чтобы убедиться, что DNS-запись для вашей конечной точки первичного сервиса (например, primary.mydomain.com) разрешается в IP-адрес нового первичного узла.

Решения:

Настройте server_reset_query: Убедитесь, что ваш пулер имеет server_reset_query (например, DISCARD ALL;) для очистки состояния сеанса при возврате соединения в пул и перед его повторным использованием другим клиентом. Это критически важно для сред, использующих временные объекты или настройки, специфичные для сеанса.
max_db_connections и max_user_connections: Установите соответствующие лимиты, чтобы предотвратить монополизацию пулером всех соединений с новым первичным узлом, что может лишить другие сервисы ресурсов.
Перезагрузка/Перезапуск пулера: В некоторых случаях может потребоваться корректная перезагрузка или перезапуск пулера соединений, чтобы заставить его принять новые конфигурации или повторно разрешить DNS. Это должно быть крайней мерой и, желательно, автоматизировано вашим менеджером переключения.
Более короткий TTL DNS: При использовании обнаружения сервисов на основе DNS настройте очень короткое время жизни (TTL) для DNS-записи первичного узла (например, 30-60 секунд), чтобы минимизировать влияние кэширования DNS.
Повторные попытки на стороне клиента: Реализуйте экспоненциальную задержку и логику повторных попыток в коде вашего приложения. Это делает приложения более устойчивыми к временным проблемам с подключением во время переключения.
Виртуальный IP (VIP): Рассмотрите возможность использования виртуального IP-адреса, управляемого вашим HA-решением. VIP перемещается вместе с первичным узлом, поэтому приложения подключаются к статическому IP-адресу, а базовый сервер базы данных меняется прозрачно.

# Пример фрагмента конфигурации PgBouncer
[databases]
mydb = host=primary_cluster_service_ip port=5432 dbname=mydb
# Или используя имя хоста, которое обновляется вашим менеджером переключения
# mydb = host=primary.mydomain.com port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = session
server_reset_query = DISCARD ALL;
server_fast_close = 1 # Закрывать соединения быстро, если сервер не отвечает
server_check_delay = 10 # Проверять работоспособность сервера каждые 10 секунд

2. Чрезмерное отставание реплики, препятствующее переключению

Отставание реплики происходит, когда резервная база данных отстает от первичной, то есть она не воспроизвела все записи WAL (журнала упреждающей записи), отправленные первичным узлом. Во время переключения повышение сильно отстающей реплики может привести к потере данных или значительно задержать процесс переключения, если HA-менеджер ждет, пока она догонит.

Симптомы проблемы:

Оповещения мониторинга указывают на большое отставание реплики (например, в байтах или времени).
Менеджеры переключения отказываются повышать реплику из-за превышения настроенного порога отставания.
После переключения приложения наблюдают отсутствие данных, которые присутствовали на старом первичном узле.

Основные причины:

Высокая нагрузка на запись на первичном узле: Устойчивый высокий объем операций записи на первичном узле может перегрузить способность реплики успевать, особенно если оборудование реплики (ввод-вывод, ЦП) уступает.
Сетевая задержка/Пропускная способность: Медленные или перегруженные сетевые каналы между первичным узлом и репликой могут задерживать передачу WAL.
Медленный ввод-вывод на реплике: Дисковая подсистема реплики может быть недостаточно быстрой для эффективной записи и воспроизведения записей WAL.
Настройка wal_level: Если wal_level не установлен в replica или выше, необходимая информация для потоковой репликации не будет генерироваться.
max_wal_senders: Недостаточное количество max_wal_senders на первичном узле может ограничить количество активных слотов репликации или одновременных соединений репликации, влияя на пропускную способность.
Проблемы с archive_command / restore_command: При использовании архивации и восстановления WAL проблемы с этими командами (например, медленное хранилище архива) могут вызывать задержки.

Шаги по отладке:

Мониторинг pg_stat_replication: Это представление предоставляет информацию в реальном времени о статусе репликации, включая write_lag, flush_lag и replay_lag.
Сравнение LSN: Вручную сравните текущий WAL LSN на первичном узле с последним воспроизведенным LSN на реплике.
Проверка системных ресурсов: Используйте iostat, vmstat, top как на первичном узле, так и на реплике для выявления узких мест ввода-вывода, насыщения ЦП или нехватки памяти.
Сетевая диагностика: Проверьте производительность сети между первичным узлом и репликой с помощью iperf.

Решения:

Увеличьте max_wal_senders: На первичном узле увеличьте max_wal_senders (например, max_wal_senders = 10), чтобы разрешить больше одновременных соединений репликации. Требуется перезапуск.
Улучшите оборудование реплики: Если ввод-вывод или ЦП являются узким местом, рассмотрите возможность модернизации оборудования реплики или оптимизации ее конфигурации хранения (например, более быстрые SSD, отдельный диск для WAL).
Настройте wal_compression: На первичном узле установка wal_compression = on может уменьшить объем WAL, потенциально улучшая скорость репликации по каналам с ограниченной пропускной способностью, но ценой загрузки ЦП первичного узла.
Настройте wal_keep_size или wal_keep_segments: Убедитесь, что на первичном узле сохраняется достаточно файлов WAL, чтобы предотвратить рассинхронизацию реплик и необходимость полной базовой резервной копии.
synchronous_commit: Хотя synchronous_commit = on обеспечивает более строгие гарантии сохранности данных, он вносит задержку для операций записи на первичном узле. Используйте remote_write или remote_apply для определенных таблиц или транзакций, если требуется строгая синхронная репликация, но тщательно оцените влияние на производительность.
Мониторинг и оповещение: Внедрите надежный мониторинг для pg_stat_replication и настройте оповещения на случай, если отставание превысит допустимые пороги.

-- На первичном узле: Проверка текущего WAL LSN
SELECT pg_current_wal_lsn();

-- На первичном узле: Проверка подключенных резервных серверов и отставания
SELECT
    usename, application_name, client_addr, state, sync_state,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes,
    write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

На резервном сервере используйте:

SELECT
    pg_is_in_recovery() AS is_standby,
    pg_last_wal_receive_lsn(),
    pg_last_wal_replay_lsn(),
    now() - pg_last_xact_replay_timestamp() AS time_since_last_replay;

Запрос с меткой времени может вводить в заблуждение в неактивной системе, поскольку никакая недавняя транзакция не могла быть воспроизведена. Используйте его вместе со сравнениями LSN и контекстом рабочей нагрузки.

3. Неудачное или зависшее переключение первичного узла

Автоматическое переключение должно быстро и надежно повышать реплику. Когда этот процесс останавливается или полностью терпит неудачу, это может привести к длительному простою и потребовать ручного вмешательства.

Симптомы проблемы:

Новый первичный узел не избирается или не повышается после выхода из строя старого первичного узла.
Кластер входит в состояние split-brain, когда два узла считают себя первичными.
Журналы менеджера переключения показывают ошибки, связанные с кворумом, выборами лидера или повышением базы данных.
Приложения остаются недоступными, поскольку нет доступного первичного узла.

Основные причины:

Split-Brain: Возникает, когда сетевые разделы изолируют узлы, что приводит к появлению нескольких первичных узлов или неоднозначным выборам первичного узла. Это самый опасный сценарий, грозящий расхождением данных.
Проблемы с кворумом: Менеджер переключения может не достичь кворума (большинства голосов) среди своих узлов, что мешает ему принять решение о повышении. Это часто встречается в кластерах с четным количеством узлов или слишком малым их количеством.
Сетевая изоляция: Узлы менеджера переключения не могут связаться друг с другом или с экземплярами PostgreSQL, что препятствует проверкам работоспособности или выполнению команд.
Недостаточные привилегии: Пользователю менеджера переключения может не хватать необходимых разрешений PostgreSQL (например, pg_promote()) или системных разрешений (например, для управления VIP).
Ошибки конфигурации: Неправильные restore_command, primary_conninfo или другие настройки в конфигурации менеджера переключения.

Шаги по отладке:

Проверьте журналы менеджера переключения: Это основной источник информации. Для Patroni смотрите его специфические журналы (часто journalctl -u patroni или файл журнала, настроенный в patroni.yml). Для pg_auto_failover проверьте journalctl -u pgautofailover_monitor и журналы агентов.
Проверьте статус кворума: Для Patroni используйте patronictl list, чтобы увидеть состояние всех членов кластера и подтвердить избранного лидера. Для pg_auto_failover проверьте pg_autoctl show state.
Сетевое подключение: Выполните проверки ping, traceroute и telnet между всеми узлами HA и распределенным хранилищем консенсуса (например, Etcd, Consul, ZooKeeper для Patroni).
Системные журналы: Проверьте journalctl -xe или /var/log/syslog на всех узлах на наличие системных ошибок, которые могут мешать работе менеджера переключения (например, заполненный диск, проблемы с памятью).
Журналы PostgreSQL: Изучите журналы PostgreSQL на кандидате в реплики для повышения, чтобы увидеть, сообщает ли он о каких-либо проблемах во время попытки повышения.

Решения:

Реализуйте Fencing/STONITH: Фенсинг (изоляция) имеет решающее значение для предотвращения split-brain, гарантируя, что вышедший из строя первичный узел не сможет продолжать принимать записи до повышения нового. Обычно это обрабатывается менеджером переключения или инфраструктурным уровнем.
Нечетное количество узлов для кворума: Всегда развертывайте нечетное количество голосующих узлов (например, 3, 5) для распределенного хранилища консенсуса вашего менеджера переключения (Etcd, Consul, ZooKeeper), чтобы гарантировать, что кворум всегда может быть достигнут, даже если один или два узла выйдут из строя.
Надежная сетевая конфигурация: Обеспечьте избыточные сетевые пути, правильные правила брандмауэра, разрешающие связь по необходимым портам (PostgreSQL, хранилище консенсуса, API Patroni), и согласованное разрешение имен хостов.
Проверка разрешений: Убедитесь, что учетная запись пользователя, запускающая менеджер переключения, имеет все необходимые привилегии PostgreSQL и системные разрешения для выполнения задач повышения и перенастройки.
Проверьте конфигурацию менеджера переключения: Перепроверьте настройки patroni.yml или pg_auto_failover на наличие опечаток, неверных путей или неправильно настроенного restore_command.
Ручное вмешательство (с осторожностью): В случае серьезного зависания переключения может потребоваться ручное повышение или повторное присоединение узлов. Действуйте с крайней осторожностью, убедившись, что старый первичный узел полностью выключен перед повышением нового, чтобы избежать расхождения данных.

# Пример: Проверка статуса кластера Patroni
patronictl -c /etc/patroni/patroni.yml list

# Ожидаемый вывод (пример):
# + Cluster: my_ha_cluster (6979219803154942080) ------+----+-----------+----+-----------+
# | Member  | Host         | Role    | State    | TL | Lag |
# +---------+--------------+---------+----------+----+-----+
# | node1   | 192.168.1.10 | Leader  | running  | 2  |     |
# | node2   | 192.168.1.11 | Replica | running  | 2  | 0   |
# | node3   | 192.168.1.12 | Replica | running  | 2  | 0   |
# +---------+--------------+---------+----------+----+-----+

4. Проблемы с сетевым подключением и разрешением DNS

В основе многих проблем HA лежат фундаментальные сетевые проблемы, препятствующие взаимодействию узлов или обнаружению приложениями правильной конечной точки базы данных.

Симптомы проблемы:

Ошибки connection refused или no route to host от приложений или между узлами кластера.
Менеджер переключения сообщает об узлах как о недоступных.
Сервисы, полагающиеся на DNS, не могут правильно разрешить имя хоста первичного узла.

Основные причины:

Правила брандмауэра: Неправильно настроенные правила брандмауэра (например, iptables, группы безопасности), блокирующие порт PostgreSQL (5432), порты менеджера переключения или порты хранилища консенсуса.
Сетевой раздел: Физический или логический сетевой раздел, препятствующий связи между подмножеством узлов.
Неправильная маршрутизация: Неправильно настроенные сетевые маршруты на одном или нескольких узлах.
Кэширование/Неправильная конфигурация DNS: Как обсуждалось в разделе 1, устаревшие записи DNS или неверная конфигурация DNS-сервера могут направлять трафик не по адресу.
Сбой миграции виртуального IP (VIP): При использовании VIP он может не мигрировать на новый первичный узел, оставляя сервис недоступным.

Шаги по отладке:

Базовая связность: Используйте ping <target_ip> между всеми узлами.
Связность по порту: Используйте telnet <target_ip> <port> (например, telnet 192.168.1.10 5432), чтобы убедиться, что порт PostgreSQL открыт и прослушивается.
Проверка брандмауэра: На каждом узле проверьте активные правила брандмауэра (sudo iptables -L, sudo ufw status или конфигурации групп безопасности облачного провайдера).
Статус сетевого интерфейса: Используйте ip addr show или ifconfig, чтобы убедиться, что сетевые интерфейсы активны и правильно настроены.
Разрешение DNS: Используйте dig <hostname> или nslookup <hostname>, чтобы проверить разрешение имени хоста с соответствующих узлов (серверы приложений, пулер, узлы HA).

Решения:

Проверьте правила брандмауэра: Убедитесь, что необходимые порты открыты для PostgreSQL (5432), плоскости управления менеджера переключения (например, 8008 для API Patroni, 8000/8001 для pg_auto_failover) и распределенного хранилища консенсуса (например, Etcd: 2379/2380, Consul: 8300/8301/8302).
Согласованная сеть: Убедитесь, что все узлы находятся в одной подсети или имеют правильную маршрутизацию, если они охватывают несколько подсетей.
Обновления DNS: Автоматизируйте обновления DNS как часть процесса переключения или используйте более короткий TTL. VIP-адреса часто предпочтительнее по этой причине.
Управление VIP: При использовании VIP убедитесь, что инструмент управления VIP (например, Keepalived, управление IP-адресами облачного провайдера) правильно настроен и работает. Явно протестируйте миграцию VIP.
Доступ на основе хоста: Для простоты в небольших кластерах убедитесь, что pg_hba.conf разрешает подключения со всех потенциальных IP-адресов первичного узла/реплики и IP-адреса пулера соединений.

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

psql: Для выполнения SQL-запросов, таких как pg_stat_replication, pg_current_wal_lsn(), команды SHOW *.
CLI менеджера переключения: patronictl, pg_autoctl для запроса состояния кластера, журналов и инициирования действий.
Системный мониторинг: Инструменты, такие как Prometheus + Grafana, Zabbix, Nagios или мониторинг облачного провайдера для получения информации в реальном времени об использовании ресурсов, отставании репликации и статусе сервисов.
journalctl / tail -f: Для просмотра системных журналов и журналов приложений.
Сетевые утилиты: ping, traceroute, telnet, iperf, netstat, dig, nslookup для диагностики связности.
dmesg: Для ошибок на уровне ядра, особенно связанных с дисковым вводом-выводом или OOM (Out Of Memory) killer.

Быстрый чек-лист для инцидентов

Когда срабатывает оповещение о переключении HA, используйте короткий чек-лист, прежде чем что-либо менять:

Подтвердите представление кластера:

patronictl -c /etc/patroni/patroni.yml list

Подтвердите собственную роль PostgreSQL на каждом доступном узле:

SELECT pg_is_in_recovery();

false означает, что узел является доступным для записи первичным узлом. true означает, что это резервный сервер. Если более одного узла сообщают false, остановитесь и рассматривайте инцидент как возможный split-brain.

Подтвердите конечную точку приложения:

dig primary-db.internal.example.com
nc -vz primary-db.internal.example.com 5432

Подтвердите цель пулера, если вы используете PgBouncer:

SHOW SERVERS;
SHOW POOLS;

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

Этот чек-лист намеренно прост. Во время реального переключения лучшая команда — та, которую каждый в команде понимает и может выполнить без догадок.

Лучшие практики для предотвращения проблем с переключением

Регулярное тестирование переключения: Регулярно моделируйте сбои первичного узла и наблюдайте за процессом переключения. Это укрепляет уверенность и выявляет неправильные конфигурации.
Надежный мониторинг и оповещение: Отслеживайте ключевые метрики, такие как отставание реплики, статус первичного узла, работоспособность пулера соединений и системные ресурсы. Настройте оповещения о любых отклонениях.
Правильная конфигурация пулера соединений: Убедитесь, что настроен server_reset_query, pool_mode соответствует вашему приложению и включены проверки работоспособности.
Настройка параметров репликации: Тщательно настройте wal_level, max_wal_senders, wal_keep_size и synchronous_commit в соответствии с вашими требованиями к производительности и надежности.
Документируйте вашу HA-установку: Четко документируйте вашу HA-архитектуру, конфигурацию менеджера переключения, сетевые настройки и процедуры восстановления.
Используйте выделенный менеджер переключения: Полагайтесь на проверенные решения, такие как Patroni или pg_auto_failover, а не на пользовательские скрипты для критически важной логики HA.
Выделенное хранилище консенсуса: При использовании менеджера, такого как Patroni, разверните отдельный высокодоступный кластер для его распределенного хранилища консенсуса (Etcd, Consul), чтобы избежать единой точки отказа.

Самые полезные тесты HA — это не чистые демонстрации, где первичный узел вежливо останавливают. Тестируйте также и сложные случаи: старый первичный узел теряет сеть, но продолжает работать, DNS обновляется медленно, PgBouncer удерживает устаревшие соединения сервера, реплика отстает на 30 секунд или хранилище консенсуса теряет участника. Эти тесты показывают, соответствуют ли ваши инструкции системе, которую вы на самом деле эксплуатируете.