GitHub полностью перестроил поисковую архитектуру Enterprise Server, избавившись от проблем, которые мучили администраторов годами. Теперь обновления и обслуживание не приведут к блокировкам системы из-за сбоев индексов Elasticsearch.
Поиск — основа работы GitHub. Он обрабатывает не только поисковые запросы и фильтры в Issues, но и страницы релизов, проектов, подсчёт pull request'ов. Раньше администраторы Enterprise Server ходили по лезвию бритвы: малейшее нарушение последовательности при обновлениях могло повредить поисковые индексы.
Корень проблемы — архитектурный конфликт
GitHub Enterprise Server использует паттерн leader/follower: основной узел обрабатывает запросы, реплики синхронизируются и готовы подхватить нагрузку. Проблема в том, что старые версии Elasticsearch не поддерживали такую схему напрямую.
Инженеры GitHub создали Elasticsearch-кластер, объединяющий основной сервер и реплики. Это работало, но создавало критическую уязвимость: Elasticsearch мог переместить primary shard на реплику. Если эту реплику потом выключали на обслуживание, система блокировалась намертво — реплика ждала восстановления Elasticsearch, а Elasticsearch не мог стартовать без реплики.
Решение через Cross Cluster Replication
Теперь GitHub использует функцию Cross Cluster Replication (CCR) из Elasticsearch. Каждый сервер Enterprise работает как независимый single-node кластер, а CCR контролируемо копирует эти между узлами — только после того, как они сохранены в Lucene-сегментах.
Это означает конец ситуациям, когда критические эти оказывались на read-only узлах. Elasticsearch теперь нативно поддерживает паттерн leader/follower, который изначально использует GitHub Enterprise Server.
Для администраторов это означает: меньше времени на «танцы с бубном» вокруг поисковых индексов, больше — на задачи, которые действительно важны для бизнеса. Обновления станут предсказуемыми, а риск потерять поиск после планового обслуживания — минимальным.
Изменения уже внедряются в новые релизы GitHub Enterprise Server.