2017-11-02 27 views
5

Chúng tôi đã phát hiện một số tài liệu trùng lặp trong một trong các chỉ mục Elasticsearch của chúng tôi và chúng tôi không thể tìm ra nguyên nhân. Có hai bản sao của mỗi tài liệu bị ảnh hưởng và chúng có chính xác cùng các trường _id, _type_uid.Tài liệu trùng lặp trong chỉ mục Elasticsearch với cùng một _uid

Một yêu cầu GET để /index-name/document-type/document-id chỉ trả về một bản sao, nhưng tìm kiếm các tài liệu với một truy vấn như thế này trả về hai kết quả, đó là khá bất ngờ:

POST /index-name/document-type/_search 
{ 
    "filter": { 
    "term": { 
     "_id": "document-id" 
    } 
    } 
} 

Tập hợp trên các lĩnh vực _uid cũng xác định các tài liệu trùng lặp :

POST /index-name/_search 
{ 
    "size": 0, 
    "aggs": { 
    "duplicates": { 
     "terms": { 
     "field": "_uid", 
     "min_doc_count": 2 
     } 
    } 
    } 
} 

Các bản sao đều ở trên các phân đoạn khác nhau. Ví dụ: tài liệu có thể có một bản sao trên phân đoạn chính 0 và một bản sao trên phân đoạn chính 1. Chúng tôi đã xác minh điều này bằng cách chạy truy vấn tổng hợp ở trên mỗi phân đoạn bằng cách sử dụng preference parameter: không tìm thấy bất kỳ bản sao nào trong một đơn shard.

Dự đoán tốt nhất của chúng tôi là đã xảy ra sự cố với định tuyến nhưng chúng tôi không hiểu cách các bản sao có thể được định tuyến đến các phân đoạn khác nhau. Theo số routing documentation, định tuyến mặc định dựa trên ID tài liệu và phải liên tục định tuyến tài liệu cho cùng một phân đoạn.

Chúng tôi hiện không sử dụng thông số định tuyến tùy chỉnh sẽ ghi đè định tuyến mặc định. Chúng tôi đã kiểm tra kỹ điều này bằng cách đảm bảo rằng các tài liệu trùng lặp không có trường _routing.

Chúng tôi cũng không xác định bất kỳ mối quan hệ cha mẹ/con nào cũng sẽ ảnh hưởng đến định tuyến. (Xem this question in the Elasticsearch forum, ví dụ, có cùng các triệu chứng như vấn đề của chúng tôi. Chúng tôi không nghĩ nguyên nhân là như nhau vì chúng tôi không đặt bất kỳ cha mẹ tài liệu nào).

Chúng tôi đã khắc phục sự cố ngay lập tức bằng cách tái lập chỉ mục vào một chỉ mục mới, đã đè bẹp các tài liệu trùng lặp. Chúng tôi vẫn có chỉ mục cũ xung quanh để gỡ lỗi.

Chúng tôi chưa tìm thấy cách sao chép sự cố. Chỉ mục mới là lập chỉ mục tài liệu chính xác và chúng tôi đã thử chạy lại công việc xử lý qua đêm cũng cập nhật tài liệu nhưng không tạo thêm bất kỳ bản sao nào nữa.

Cụm có 3 nút, 3 đoạn chính và 1 bản sao (nghĩa là 3 bản sao). minimum_master_nodes được đặt thành 2, điều này sẽ ngăn chặn sự cố split-brain. Chúng tôi đang chạy Elasticsearch 2.4 (mà chúng tôi biết là cũ - chúng tôi đang có kế hoạch nâng cấp sớm).

Có ai biết điều gì có thể gây ra những bản sao này không? Bạn có bất kỳ đề xuất nào về cách gỡ lỗi không?

Trả lời

3

Chúng tôi đã tìm thấy câu trả lời! Vấn đề là chỉ số đã bất ngờ chuyển thuật toán băm mà nó sử dụng để định tuyến, và điều này gây ra một số tài liệu cập nhật được lưu trữ trên các phân đoạn khác nhau cho các phiên bản gốc của chúng.

Một yêu cầu GET để /index-name/_settings tiết lộ này:

"version": { 
    "created": "1070599", 
    "upgraded": "2040699" 
}, 
"legacy": { 
    "routing": { 
    "use_type": "false", 
    "hash": { 
     "type": "org.elasticsearch.cluster.routing.DjbHashFunction" 
    } 
    } 
} 

"1.070.599" đề cập đến Elasticsearch 1,7, và "2.040.699" là ES 2.4.

Dường như chỉ mục đã cố nâng cấp từ 1,7 lên 2.4, mặc dù thực tế là nó đã chạy 2.4. Đây là vấn đề được mô tả ở đây: https://github.com/elastic/elasticsearch/issues/18459#issuecomment-220313383

Chúng tôi nghĩ rằng đây là những gì đã xảy ra để kích hoạt sự thay đổi:

  1. Quay lại khi chúng tôi nâng cấp các chỉ số từ ES 1,7-2,4, chúng tôi quyết định không nâng cấp Elasticsearch trong- vì nó sẽ gây ra thời gian chết. Thay vào đó, chúng tôi đã tạo một cụm ES 2.4 riêng biệt.

    Chúng tôi đã tải dữ liệu vào cụm mới bằng cách sử dụng công cụ được sao chép qua tất cả cài đặt chỉ mục cũng như dữ liệu, bao gồm cài đặt version có cài đặt you should not set in ES 2.4.

  2. Trong khi xử lý sự cố gần đây, chúng tôi tình cờ đóng và mở lại chỉ mục. Điều này thường bảo toàn tất cả dữ liệu, nhưng do cài đặt version không chính xác, điều này đã khiến Elasticsearch nghĩ rằng bản nâng cấp đã được xử lý.

  3. ES tự động đặt cài đặt legacy.routing.hash.type do nâng cấp sai. Điều này có nghĩa rằng bất kỳ dữ liệu nào được lập chỉ mục sau thời điểm này đã sử dụng DjbHashFunction cũ thay vì mặc định Murmur3HashFunction đã được sử dụng để định tuyến dữ liệu ban đầu.

Điều này có nghĩa là việc lập lại dữ liệu vào chỉ mục mới là điều đúng đắn cần làm để khắc phục vấn đề. Chỉ mục mới có cài đặt phiên bản chính xác và không có cài đặt hàm băm cũ:

"version": { 
    "created": "2040699" 
} 
Các vấn đề liên quan