How we rebuilt the search architecture for high availability in GitHub Enterprise Server

GitHub · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

Trong GitHub Enterprise Server (bản tự host), search không chỉ là ô tìm kiếm: trang Issues, releases, projects, số đếm issue và PR đều dựa vào nó.
Bản HA của GHES theo mẫu leader/follower: primary nhận mọi ghi, replica chỉ đọc và sẵn sàng thay thế. Mẫu này ăn sâu vào mọi thao tác vận hành.
Elasticsearch (bản cũ) không có mô hình primary/replica như vậy, nên GitHub dựng một cụm Elasticsearch trải qua cả node primary và replica. Lợi: replication đơn giản, mỗi node tự phục vụ search cục bộ.
Hại, theo thời gian lớn hơn lợi: Elasticsearch có thể dời primary shard sang node replica. Nếu replica đó được tắt để bảo trì thì GHES kẹt: replica chờ Elasticsearch khoẻ mới khởi động, Elasticsearch chờ replica quay lại mới khoẻ. Admin làm sai thứ tự bước bảo trì hay nâng cấp là index hỏng hoặc bị khoá.
Nhiều bản phát hành liên tiếp họ thêm kiểm tra sức khoẻ, quy trình sửa trạng thái trôi, thậm chí thử tự viết "search mirroring", nhưng tự làm replication cho nhất quán là quá khó.

Dùng Cross Cluster Replication (CCR) của Elasticsearch: mỗi node GHES chạy một cụm Elasticsearch một node, độc lập; CCR chép dữ liệu từ leader sang follower sau khi đã ghi bền vào segment Lucene. Elasticsearch giờ có đúng mẫu leader/follower của GHES, nên dữ liệu quan trọng không còn rơi vào node chỉ đọc.
Bootstrap: auto-follow chỉ áp cho index tạo sau khi có policy, mà GHES có sẵn nhiều index sống lâu; nên phải gắn follower cho từng index hiện có (bỏ index hệ thống), rồi mới bật auto-follow cho index mới.
Elasticsearch chỉ lo replication document; GitHub tự viết workflow cho failover, xoá index, nâng cấp.
Rollout: tuỳ chọn từ bản 3.19.1 (bật cờ cấu hình rồi config-apply/nâng cấp); khi khởi động lại, dữ liệu được gom về primary, bỏ cụm trải node, bật replication bằng CCR. Sẽ thành mặc định trong hai năm tới để admin kịp phản hồi.

Cụm phân tán trải qua cả "primary" lẫn "replica" của một hệ HA tạo phụ thuộc vòng khi bảo trì: hai bên chờ nhau (Độ tin cậy và multi-region).
Mô hình HA của thành phần con phải khớp mô hình HA của hệ chứa nó (leader/follower với leader/follower).
Đừng tự viết replication khi hệ lưu trữ đã có cơ chế gốc; phần còn lại (failover, vòng đời index) mới là việc của mình.
Phần mềm khách tự host: đổi kiến trúc qua cờ tuỳ chọn, migration tự chạy khi khởi động, thời gian chuyển dài (hai năm) (Migration không downtime).