Bản sao Cassandra xuống trong khi sửa chữa nodetool?

Question

Tôi đang phát triển một kịch bản tự động cho sửa chữa nodetool mà sẽ thực hiện bao giờ cuối tuần trên tất cả 6 nút Cassandra. Chúng ta có 3 trong DC1 và 3 trong DC2. Chỉ muốn hiểu trường hợp xấu nhất. Điều gì sẽ xảy ra nếu kết nối giữa DC1 và DC2 bị mất hoặc một vài bản sao đi xuống trước hoặc trong quá trình sửa chữa nodetool. Nó có thể là một vấn đề mạng, một nâng cấp mạng (thường xảy ra vào cuối tuần), hoặc cái gì khác. Tôi hiểu rằng sửa chữa nodetool tính toán một cây Merkle cho mỗi phạm vi dữ liệu trên nút đó, và so sánh nó với các phiên bản trên các bản sao khác. Vì vậy, nếu họ không có kết nối giữa các bản sao như thế nào một sửa chữa nodetool sẽ hành xử? Nó sẽ thực sự sửa chữa các nút. Tôi có phải chạy lại công cụ sửa chữa nút sau khi tất cả các nút đang hoạt động và kết nối được khôi phục hay không. Liệu họ có bị bất kỳ tác dụng phụ nào của sự kiện này không? Tôi goggled về nó nhưng không thể tìm thấy nhiều chi tiết. Bất kỳ cái nhìn sâu sắc sẽ là hữu ích.

Cảm ơn.

Answer 1

Giả sử bạn đang sử dụng vnodes, theo mặc định có nghĩa là mỗi nút có 256 phạm vi, nhưng ý tưởng là như nhau.

Nếu sự cố mạng xảy ra sau khi sửa chữa nodetool đã bắt đầu, bạn sẽ thấy trong nhật ký là một số phạm vi được sửa chữa thành công và các phạm vi khác thì không. Lỗi sẽ nói rằng việc sửa chữa phạm vi không thành công vì nút "192.168.1.1 đã chết" giống như vậy.

Nếu lỗi mạng xảy ra trước khi sửa chữa nodetool bắt đầu, tất cả các phạm vi sẽ không thành công với cùng một lỗi.

Trong cả hai trường hợp, bạn sẽ cần phải chạy một sửa chữa nodetool khác sau khi sự cố mạng được giải quyết.

Tôi không biết lượng dữ liệu bạn có trong 6 nút đó, nhưng theo kinh nghiệm của tôi nếu cụm có thể xử lý nó tốt hơn là chạy sửa chữa nodetool một lần một tuần vào một ngày khác trong tuần. Ví dụ, bạn có thể sửa chữa nút 1 vào Chủ Nhật, nút 2 vào thứ Hai và cứ tiếp tục như vậy. Nếu bạn có một lượng nhỏ dữ liệu hoặc thêm/cập nhật trong một ngày không quá nhiều, bạn thậm chí có thể chạy sửa chữa một lần một ngày. Khi bạn có một cụm đã được sửa chữa và bạn chạy nodetool sửa chữa thường xuyên hơn, nó sẽ mất ít thời gian hơn để hoàn thành, nhưng một lần nữa nếu bạn có quá nhiều dữ liệu trong nó nó có thể không được.

Về tác dụng phụ bạn chỉ có thể lưu ý sự khác biệt trong dữ liệu nếu bạn sử dụng mức nhất quán 1, nếu xảy ra việc bạn chạy truy vấn với nút "không được sửa chữa", dữ liệu sẽ khác với dữ liệu được sửa chữa "nút. Bạn có thể giải quyết điều này bằng cách tăng mức độ nhất quán lên 2 ví dụ, sau đó lại nếu 2 nút "không được sửa chữa" và truy vấn bạn chạy được giải quyết bằng 2 nút đó, bạn sẽ thấy sự khác biệt một lần nữa. Bạn có một sự cân bằng ở đây vì tùy chọn tốt nhất để tránh "sự khác biệt" này trong các truy vấn là có hệ số nhân bản = mức nhất quán, điều này mang lại một vấn đề khác khi 1 trong số các nút nằm xuống toàn bộ cụm. bắt đầu nhận thời gian chờ trên truy vấn của bạn.

Hy vọng điều đó sẽ hữu ích!

Answer 2

Có nhiều tùy chọn sửa chữa có sẵn, bạn có thể chọn tùy chọn tùy thuộc vào mức sử dụng ứng dụng của bạn. Nếu bạn đang sử dụng DSE Cassandra sau đó tôi sẽ khuyên bạn nên lên lịch sửa chữa OpsCenter mà không sửa chữa gia tăng bằng cách cho thời gian ít hơn gc_grace_seconds.

Sau đây là tùy chọn khác nhau để làm sửa chữa:

1. Mặc định (Không): Sẽ sửa chữa tất cả 3 dải phân vùng: 1 chính và 2 bản sao thuộc sở hữu của các nút trên đó nó được chạy. Tổng cộng 5 nút sẽ được tham gia 2 nút sẽ được sửa chữa 1 phạm vi phân vùng, 2 nút sẽ được sửa chữa 2 phạm vi phân vùng, 1 nút sẽ được sửa chữa 3 phạm vi phân vùng.
2. -par: Sẽ thực hiện thao tác trên song song.
3. -pr: Sẽ chỉ sửa phạm vi phân vùng chính cho nút mà trên đó nó được chạy. Nếu bạn đang sử dụng tính nhất quán ghi của EACH_QUORUM thì hãy sử dụng tùy chọn -local để giảm lưu lượng qua DC.

Tôi khuyên bạn nên sử dụng tùy chọn 3 nếu bạn đã trực tiếp sản xuất để tránh bất kỳ tác động hiệu suất nào do sửa chữa.

Nếu bạn muốn đọc chi tiết về sửa chữa, vui lòng xem tại đây here