GitHub полностью переписал поисковую архитектуру Enterprise Server, устранив критические проблемы с индексами Elasticsearch. Теперь администраторам не нужно соблюдать строгий порядок обслуживания — система стала устойчивой к сбоям.
Поиск в GitHub — основа платформы. Он работает не только в поисковых строках, но и обеспечивает фильтрацию Issues, страницы релизов, подсчёт пулл-реквестов и проекты. Любые проблемы с поиском парализуют всю работу команды.
В предыдущих версиях администраторы Enterprise Server сталкивались с коварной проблемой. При неправильной последовательности обновлений поисковые индексы повреждались или блокировались. Система могла войти в deadlock: реплика ждала восстановления Elasticsearch, а Elasticsearch не мог запуститься без реплики.
Проблема кластеризации
Корень зла — в архитектуре Elasticsearch. High Availability установки GitHub используют схему лидер/последователь: основной узел принимает все записи, реплики синхронизируются и готовы перехватить управление.
Elasticsearch не поддерживал такую модель из коробки. Инженеры GitHub создавали кластер Elasticsearch поверх основного и резервных узлов. Это давало производительность — каждый узел обрабатывал поисковые запросы локально.
Но Elasticsearch мог в любой момент переместить primary shard на реплику. Если эту реплику отключали для обслуживания, вся система блокировалась.
Новое решение
GitHub перешёл на Cross Cluster Replication (CCR) — функцию Elasticsearch для репликации между кластерами. Теперь каждый сервер Enterprise работает как независимый однонодовый кластер Elasticsearch.
CCR копирует эти только после записи в Lucene-сегменты — базовое хранилище Elasticsearch. Это гарантирует репликацию только устойчиво сохранённых данных.
"Теперь, когда Elasticsearch поддерживает схему лидер/последователь нативно, администраторы больше не столкнутся с ситуацией, когда критически важные эти оказываются на read-only узлах", — поясняет команда GitHub.
Практические выводы
Для команд на GitHub Enterprise Server это означает меньше времени на администрирование и больше — на разработку. Исчезли требования к строгой последовательности обновлений и риски повреждения поисковых индексов.
Изменение затронет новые версии GitHub Enterprise Server — миграция на новую архитектуру будет происходить автоматически при обновлении.
