Chiến lược sao lưu dự phòng Elasticsearch

Question

Sẽ thật thú vị nếu ai đó có thể chia sẻ các chiến lược 'sao lưu nóng' tốt nhất của mình cho ElasticSearch.

Ngoài ra, vui lòng chia sẻ các công cụ và thư viện liên quan đến vấn đề này và có thể trợ giúp.

Đã cập nhật: Cảm ơn bạn @javanna vì câu trả lời của bạn, nó khá hoàn chỉnh và cung cấp hướng tốt cho các hành động khác.

Tôi cũng đã thực hiện một nghiên cứu nhỏ và tìm thấy một số bài báo/thảo luận có thể giúp ích nếu ai đó quan tâm.

• Elasticsearch backup strategies
• Backup/restore Elasticsearch index và related snippet on github:gist
• Elastic Search Backup and Recovery thảo luận (đánh dấu những nhận xét của Paul Smith, cũng ông đã chia sẻ một liên kết hữu ích để mình tool for verifying indexes)

Cập nhật: Elasticsearch 1.0 có một giải pháp sao lưu "chính thức" - Snapshot/Restore API và đây là cách duy nhất phù hợp với nó ngay bây giờ. ElasticSearch sẽ xác định các phân đoạn chính và cẩn thận về tính nhất quán. Việc sao lưu sẽ được thực hiện từng bước, vì vậy bạn sẽ có thể thực hiện nó rất nhanh và thường xuyên như bạn muốn.

Answer 1

Bản sao là một loại sao lưu và elasticsearch không bao giờ phân bổ một trên cùng một nút nơi phân đoạn chính ban đầu. Nhưng sau đó vẫn có nguy cơ mất dữ liệu tùy thuộc vào bao nhiêu mảnh, bản sao và các nút bạn có trong cụm của bạn.

Tôi sẽ xem mô-đun Gateway, qua đó bạn có thể lưu chỉ mục và siêu dữ liệu cụm. Có nhiều loại cổng khác nhau. Tôi muốn xem ví dụ Shared FS, cho phép bạn sao chép chỉ mục và siêu dữ liệu vào hệ thống tệp được chia sẻ giữa tất cả các nút của bạn. Bạn cũng có thể tự khởi động ảnh chụp nhanh qua Gateway Snapshot API.

Ngoài ra, bạn có thể tạo bản sao của thư mục dữ liệu (trên mỗi nút) sau khi bạn tắt tính năng xả qua index.translog.disable_flush index setting. Bằng cách đó bạn sẽ đảm bảo rằng không có cam kết rõ ràng sẽ được ban hành trong khi bạn đang sao chép. Sau khi bạn tạo bản sao, bạn cần kích hoạt lại.

CẬP NHẬT

Tất cả các loại cửa ngõ ngoại trừ một địa phương đã được chấp nhận và sẽ bị loại bỏ trong một phiên bản tương lai. Elasticsearch 1.0 sẽ được phát hành với một giải pháp sao lưu tốt hơn.

Answer 2

Vì vậy, điều này đi ngược lại cách thức hoạt động của ElasticSearch, nhưng tôi muốn xem xét có 2 cá thể ElasticSearch riêng biệt không nhận thức được nhau. Trong mã ứng dụng của bạn, mọi lệnh được gửi tới cả hai phiên bản. Nếu một lệnh không thành công cho 1 thể hiện, hãy thử lại lệnh sau 1 phút, và tiếp tục thử lại. Bây giờ bạn có thể giữ 1 trong các trường hợp như một bản sao lưu nóng, hoặc thậm chí bạn có thể sử dụng nó để cải thiện hiệu năng bằng cách cân bằng tải các truy vấn giữa 2 trường hợp.

Lý do tại sao tôi không thích thiết lập bản sao trong ElasticSearch là một nỗi đau để định cấu hình nút nào nhận được bản sao và nếu bạn muốn sắp xếp lại tổ chức trong tương lai, về cơ bản bạn phải trải qua một tấn hoops. ElasticSearch thực hiện một tấn tái cân bằng đằng sau hậu trường và cố gắng làm mọi thứ cho bạn. Mà có thể là tốt ..nếu bạn có các máy chủ mạnh mẽ và không quan tâm đến những gì có được .. nhưng có thể là một nỗi đau khác.