BiHA выбрала нового лидера. Но тест ещё не пройден: 1С могла остаться на прежнем адресе и отвечать пользователям ошибками записи.
Во время проверки нужны три результата. BiHA выбрала нового лидера, 1С записала данные через штатный адрес, прежний лидер вернулся синхронизированным последователем. Статуса Cluster OK для зачёта мало.
BiHA входит в Postgres Pro Standard 17 и 18, а также в Enterprise. Набор функций зависит от редакции и версии. Перед испытанием сверьте свою поставку с документацией к ней. Редакции перечислены в техническом обзоре Postgres Professional, а устройство кластера описывает документация Postgres Pro Enterprise 18.
Испытывайте кластер на отдельном контуре. Воспроизведите боевой маршрут подключения: серверы 1С, прокси перед СУБД, параметры соединения и правила межсетевого экрана. Иначе проверите одну BiHA, а не систему, которая должна пережить сбой.
До отключения лидера зафиксируйте исходное состояние
Сначала снимите топологию через bihactl. Утилита показывает конфигурацию и состояние кластера: текущего лидера, последователей и параметры узлов.
Этот снимок понадобится после переключения. Без сравнения легко пропустить частичное восстановление. Новый лидер уже работает, но один последователь выпал из голосования или не догнал WAL.
WAL — журнал изменений PostgreSQL. Последователи получают его от лидера через физическую потоковую репликацию. По актуальности WAL BiHA оценивает, насколько кандидат отстал от прежнего лидера.
| Что зафиксировать | Где посмотреть | Зачем проверять после переключения |
|---|---|---|
| Текущие роли узлов | Состояние кластера в bihactl | Подтвердить, что прежний последователь стал лидером, а не остался читающей репликой |
| Состав голосующих узлов | Конфигурация узлов BiHA | Понять, из каких голосов сложился кворум |
Значение biha.nquorum | Конфигурация кластера | Сопоставить число доступных голосов с условием выборов |
| Режим репликации | Параметры BiHA и PostgreSQL | Учесть отставание последователя при асинхронной работе |
| Состояние последователей | Статус узлов и репликации | Не запускать переключение на уже проблемном контуре |
| Маршрут подключения 1С | Настройки подключения и прокси | Проверить тот же адрес после смены лидера |
Вывод: исходный снимок показывает разницу между простой сменой роли и полным восстановлением кластера.
Сохраните вывод bihactl и запишите время начала опыта. Не назначайте норматив переключения до первого испытания своей системы. Документация объясняет выборы, но не обещает срок для вашей сети, базы и нагрузки.
Теперь выполните контрольную операцию в 1С. Она должна прочитать данные, создать тестовую запись и найти её повторным чтением. Сохраните идентификатор объекта или другой признак, который сможете проверить после отказа.
Не используйте необратимую хозяйственную операцию. Испытательный документ, отдельный регистр или служебная обработка дадут тот же результат, но не испортят учёт.
Проверьте потерю лидера при сохранённом кворуме
В основном опыте изолируйте текущего лидера от остальных узлов. При этом большинство голосующих участников должно видеть друг друга. Остановка экземпляра СУБД и сетевой разрыв имитируют разные отказы.
Для проверки потери связи между площадками разорвите сеть. Остановка процесса PostgreSQL такой сценарий не воспроизведёт. Если проверяете отказ СУБД, не добавляйте сетевую блокировку: она смешает две причины. В протоколе точно запишите, что отключили.
BiHA проводит автоматические выборы по алгоритму Raft. Согласно описанию Postgres Professional, для решения нужен кворум. Среди допустимых кандидатов кластер сравнивает приоритеты узлов и актуальность LSN в WAL.
LSN — позиция записи в журнале WAL. Чем ближе LSN кандидата к позиции прежнего лидера, тем меньше изменений ему недостаёт.
| Этап | Ожидаемое состояние BiHA | Проверка через 1С | Признак провала |
|---|---|---|---|
| Лидер изолирован | Остальные узлы обнаружили потерю лидера | Подключение может кратко прерваться | Прежний лидер принимает запись из изолированного сегмента |
| Идут выборы | Доступно достаточно голосов для biha.nquorum | Новые операции ещё не подтверждают успех | Выборы не начинаются при сохранённом большинстве |
| Выбран новый лидер | Один из последователей получил роль лидера | Повторите вход и чтение тестового объекта | 1С не восстанавливает соединение |
| Новый лидер принимает запись | Узел открыт для пишущих транзакций | Создайте второй тестовый объект и прочитайте его | Чтение работает, а запись заканчивается ошибкой |
| Кластер работает без старого узла | Роли остальных участников стабильны | Повторите прикладную операцию | Роли снова меняются либо соединение 1С продолжает обрываться |
Вывод: смена лидера сама по себе ничего не доказывает. Опыт засчитывается после записи через штатный маршрут 1С.
Не заменяйте автоматические выборы ручным назначением лидера. В BiHA есть ручное переключение, в том числе функция biha.set_leader. Но такая проверка отвечает лишь на вопрос, можете ли вы назначить узел. Поведение кластера при отказе останется неизвестным.
Когда новый лидер появился, сначала проверьте состояние BiHA. Потом повторите операцию через 1С, не подменяя адрес подключения вручную. Иначе ошибка в прокси, DNS или строке соединения останется незаметной.
Длительность недоступности считайте по журналам и прикладной проверке. Это результат вашего опыта, а не универсальное свойство BiHA. Если первый запуск прошёл на простаивающей базе, повторите его под обычной рабочей нагрузкой.
Потеря кворума должна остановить автоматические выборы
Переключение при доступном большинстве проверяет лишь одну сторону защиты. Вторая — кластер не должен назначать лидера, когда большинства голосов нет.
Кворум не даёт двум изолированным частям кластера принимать запись одновременно. Без этого истории WAL разойдутся. После восстановления связи они не сольются автоматически в одну непротиворечивую базу.
В кластере из двух узлов голосование легко заканчивается ничьей. Для такой схемы BiHA поддерживает рефери. Он голосует, но лидером не становится. Документация Postgres Professional описывает два режима: referee и referee_with_wal.
До опыта проверьте, какие узлы голосуют и чему равен biha.nquorum. Дальше используйте эту развилку:
- Большинство голосов доступно — кластер должен выбрать нового лидера.
- Большинства нет — новый лидер появляться не должен.
- Голосов хватает, но выборы не закончились — проверьте доступность участников, приоритеты кандидатов и актуальность WAL.
- Лидер появился без требуемого большинства — остановите испытание и ищите ошибку конфигурации.
Не меняйте biha.nquorum посреди проверки, чтобы выборы наконец состоялись. Такая правка подгонит кластер под подготовленный отказ. Его поведение без администратора вы всё равно не узнаете.
Проверьте маршрут записи через Proxima
Статус BiHA описывает состояние СУБД. Куда после выборов подключилась 1С, по нему не видно.
Если перед кластером стоит Proxima, обычная нагрузка и запись должны идти по направлению P2L — Proxy-to-Leader. В техническом обзоре Postgres Professional сказано, что Proxima получает изменения состояния BiHA через колбэки и переводит подключения на текущего лидера.
Направление P2F работает иначе: распределяет читающие запросы по последователям. Поэтому успешный отчёт через P2F не доказывает, что 1С запишет данные после аварии.
Проверьте всю прикладную цепочку:
- Запустите клиент 1С через обычный адрес.
- Откройте тестовые данные, созданные до отключения лидера.
- Создайте новую тестовую запись.
- Завершите транзакцию.
- Перечитайте запись через новое подключение.
Если SQL-сеанс с новым лидером открывается, но 1С не пишет, разрыв находится выше СУБД. Проверьте направление P2L, смену адресата после колбэка, пул старых соединений и маршрут от серверов приложений.
Резервирование СУБД не защищает от отказа ragent, rmngr или rphost. Эти сценарии нужно испытывать отдельно при настройке отказоустойчивого кластера 1С.
Верните прежний лидер и дождитесь роли последователя
После восстановления связи прежний лидер не должен забирать старую роль. BiHA переводит его в последователи и синхронизирует с текущим лидером.
Если журналы разошлись, кластер удаляет конфликтующий хвост WAL через WAL trimming либо применяет pg_rewind. Оба механизма описывает Postgres Professional. Не пересобирайте узел вручную до диагностики: иначе штатный возврат проверить не получится.
Наблюдайте за вернувшимся узлом до стабильного состояния. BiHA переводит участника в Node Error, когда закончился нужный WAL, стал недействительным слот репликации, произошла ошибка синхронизации или rewind, либо разошлись истории WAL.
| Что видно после возврата | Что проверять | Следующее действие |
|---|---|---|
| Узел стал последователем | Он подключён к текущему лидеру и получает WAL | Дождаться синхронизации и снова снять состояние кластера |
| Узел остаётся в переходном состоянии | Идёт ли передача WAL, меняется ли позиция репликации | Не завершать опыт до стабилизации состояния |
| Отставание сохраняется | Доступен ли нужный WAL и действует ли слот репликации | Проверить журналы PostgreSQL и параметры репликации |
Появился Node Error | Ошибки WAL, слота, синхронизации или pg_rewind | Сохранить журналы и устранить указанную причину до нового опыта |
| Узел пытается работать лидером | Не возникла ли изолированная пишущая сторона | Остановить запись, затем сверить кворум с сетевой схемой |
| Все узлы вернулись в штатные роли | Нет аварийных состояний, последователи получают WAL | Повторить чтение и запись через 1С |
Вывод: прежний лидер вернулся штатно, только когда стал последователем и возобновил репликацию.
Зелёного статуса узла недостаточно. Создайте ещё одну тестовую запись через 1С и проверьте, дошла ли она до последователя. Используйте штатные средства PostgreSQL и BiHA, доступные в вашей версии.
Если отдельного контура нет, соберите его из оборудования, которое уже не выдерживает боевую нагрузку. В материале про резервный стенд из списанного сервера описано, как проверить диски, питание, сеть и восстановление базы перед запуском.
От стенда не нужна производительность боевой системы. Нужны та же топология, те же версии, маршрут подключения и порядок переключения. Но время недоступности измеряйте на контуре, близком к боевому по сети и нагрузке.
Запишите результат как протокол, а не впечатление
Сохраните четыре группы данных: состояние до отказа, момент изоляции лидера, результат прикладной записи и состояние после возврата узла. Тогда другой администратор сможет повторить опыт после обновления Postgres Pro или изменения сети.
Фраза «переключение прошло нормально» для протокола бесполезна. Запишите имя выбранного лидера, доступные голоса, результат записи через 1С и конечную роль каждого узла.
Тест пройден, только если выполнены четыре условия:
- BiHA выбрала нового лидера при сохранённом кворуме;
- 1С прочитала данные и записала новую операцию через штатный адрес;
- прежний лидер после возврата стал последователем;
- все узлы вышли из аварийных состояний и возобновили репликацию.
Кворум есть, а лидера нет — сверяйте голоса, приоритеты и WAL кандидатов. Лидер выбран, но 1С не пишет — проверяйте маршрут подключения и P2L. Прежний лидер вернулся в Node Error — изучайте WAL, слот репликации и работу pg_rewind.
Не переносите время переключения и возможную потерю последних транзакций из чужой схемы. Измерьте оба значения на своём контуре с выбранным режимом репликации. По ним и решайте, укладывается ли кластер в требования компании.