Elasticsearch: có replica vì sao vẫn cần snapshot backup?

Một cụm Elasticsearch có replica vẫn có thể mất dữ liệu cần phục hồi. Replica giúp hệ thống duy trì khả năng phục vụ khi phần cứng gặp sự cố, nhưng không giữ lại lịch sử độc lập trước mọi thao tác ghi sai. Muốn quay lại dữ liệu trước một lỗi ứng dụng, đội vận hành cần cơ chế backup và quy trình khôi phục đã được kiểm tra.

Bài viết này giải thích ba lớp thường bị nhầm: bản sao shard trong cụm, sao chép giữa các cụm và snapshot. Nội dung dựa trên tài liệu Elastic hiện hành, không phải một bản vá hoặc tính năng mới công bố. Với hệ thống dùng phiên bản cũ, cần đối chiếu tài liệu đúng phiên bản trước khi áp dụng cấu hình cụ thể.

Replica bảo vệ tính sẵn sàng như thế nào?

Theo tài liệu về cluster, node và shard, Elasticsearch chia index thành các primary shard; replica shard là bản sao của primary. Phân bố các bản sao trên các node giúp chịu lỗi phần cứng và có thể tăng năng lực phục vụ truy vấn đọc.

Nhưng replica tham gia cùng trạng thái dữ liệu đang hoạt động. Nếu ứng dụng gửi một thao tác xóa hợp lệ nhưng sai nghiệp vụ, mục tiêu của hệ thống là thực hiện thao tác đó nhất quán. Việc có nhiều bản sao không tự tạo ra một phiên bản lịch sử để người quản trị quay lại trước lúc xóa.

Có thể kiểm tra sự khác biệt bằng hai câu hỏi: mất một node thì dịch vụ còn chạy không, và phát hiện dữ liệu bị ghi sai từ hôm qua thì lấy lại ở đâu? Câu đầu thuộc tính sẵn sàng; câu sau thuộc khả năng phục hồi. Một kiến trúc tốt cần có câu trả lời riêng cho cả hai.

Đồng bộ sang cụm khác vẫn cần hiểu đúng phạm vi

Cross-cluster replication, hay CCR, sao chép hoạt động từ leader index sang follower ở cụm khác. Cách tách cụm có thể hỗ trợ phương án dự phòng khi hạ tầng chính gặp sự cố, nhưng cần theo dõi độ trễ và tình trạng sao chép thực tế.

Một chi tiết quan trọng trong tài liệu Elastic là CCR truyền thao tác xóa ở cấp document, nhưng không truyền việc xóa cả leader index thành xóa follower index tương ứng. Hai hành vi này không nên bị gộp thành khẳng định rằng mọi lệnh xóa đều được sao chép, hoặc rằng cụm thứ hai luôn giữ được dữ liệu trước sai sót.

CCR cũng không tự sao chép toàn bộ cấu hình phục vụ khôi phục, như mọi template, chính sách vòng đời, quyền người dùng và cấu hình cụm. Khi đánh giá khả năng chuyển đổi vận hành, cần kiểm tra những phụ thuộc ngoài dữ liệu index. Một cụm chứa bản sao tài liệu chưa chắc đã đủ để ứng dụng hoạt động đúng ngay lập tức.

Snapshot lưu lại trạng thái để phục hồi

Snapshot của Elasticsearch sao chép các segment của index vào repository. Vì segment là bất biến, hệ thống có thể chỉ chép những segment mới và khử trùng lặp giữa các snapshot, thay vì mỗi lần đều sao chép lại toàn bộ nội dung.

Điều này giúp hiểu đúng chi phí lưu trữ: lịch chụp dày hơn không nhất thiết tương đương nhiều bản sao đầy đủ, nhưng vẫn phải đo dung lượng tăng thêm, lưu lượng mạng và thời gian hoàn thành. Với dữ liệu ghi liên tục, tần suất backup cần gắn với lượng dữ liệu tối đa có thể chấp nhận mất, thay vì chọn một khoảng giờ chỉ vì dễ đặt lịch.

Snapshot cũng không phải ảnh chụp đồng thời tuyệt đối của mọi shard tại một thời điểm duy nhất. Elastic mô tả dữ liệu từng shard nằm trong khoảng bắt đầu và kết thúc snapshot. Nếu nghiệp vụ cần tính nhất quán xuyên nhiều nguồn dữ liệu, thiết kế phục hồi phải xét thêm quan hệ giữa Elasticsearch và các hệ thống đó.

Vì sao không chép trực tiếp thư mục dữ liệu?

Elastic cảnh báo việc sao chép thư mục dữ liệu của các node không phải cách backup cụm được hỗ trợ. Những yêu cầu nhất quán trải trên toàn cluster khiến tập tệp sao chép có thể không đại diện cho một trạng thái có thể phục hồi. Khôi phục trông có vẻ thành công cũng chưa chứng minh không mất dữ liệu âm thầm.

Cần phân biệt thư mục dữ liệu node với repository snapshot đã được Elasticsearch tạo đúng quy trình. Backup repository là một bài toán khác và phải giữ nguyên tính toàn vẹn của nó. Không tự sửa, xóa hoặc thêm tệp trong repository như với một thư mục tài liệu thông thường.

Đối với dữ liệu liên tục, phương án thực dụng là phối hợp nhiều lớp: replica cho lỗi node, cụm dự phòng nếu có yêu cầu chuyển đổi nhanh, và snapshot có lịch sử cho nhu cầu quay lại trạng thái trước lỗi. Từng lớp cần quyền truy cập và khả năng bị ảnh hưởng bởi cùng một sự cố được đánh giá riêng.

Đo khả năng khôi phục bằng một lần phục hồi thật

Snapshot Lifecycle Management cho phép tự động hóa tạo snapshot và áp dụng quy tắc lưu giữ. Khi triển khai, cần giám sát kết quả hoàn thành, phạm vi index được đưa vào và tình trạng repository; chỉ thấy lịch tác vụ tồn tại chưa đủ chứng minh backup có thể dùng.

Theo hướng dẫn restore, phiên bản snapshot và cluster đích phải tương thích. Việc thử phục hồi nên diễn ra trên môi trường riêng có đủ tài nguyên, sau đó kiểm tra phạm vi thời gian, dữ liệu đại diện, truy vấn và khả năng ứng dụng đọc được kết quả.

Hai con số hữu ích là mức dữ liệu có thể mất và thời gian cần để khôi phục dịch vụ. Chúng phải được đo trong hoàn cảnh của hệ thống, không thể suy ra chỉ từ việc có replica hoặc một cụm thứ hai. Một lần diễn tập có ghi nhận thời gian và dữ liệu kiểm tra sẽ cho câu trả lời đáng tin hơn trạng thái màu xanh trên màn hình quản trị.

Nguồn và ảnh minh họa

Nguồn: Elastic Docs về shard và replica, CCR, snapshot và giới hạn sao chép filesystem, lập lịch snapshot và khôi phục. Bài không công bố kết quả benchmark hoặc diễn tập trên một hệ thống cụ thể.

Ảnh minh họa thiết bị lưu trữ ngoài dùng cho backup: Armchair, năm 2015, qua Wikimedia Commons, giấy phép CC BY-SA 4.0, sử dụng nguyên bản. Đây là ảnh minh họa lưu trữ, không phải ảnh một cụm Elasticsearch hay khuyến nghị dùng riêng ổ USB làm chiến lược backup.