Cassandra: bảo trì

Tôi chưa có kinh nghiệm với Cassandra, nhưng tôi có một số kinh nghiệm với cơ sở dữ liệu quan hệ dựa trên SQL.

Tôi đã không thể tìm thấy thông tin thực tiễn tốt nhất về cách duy trì Cassandra sau khi được triển khai. Có cần thiết phải VACUUM cơ sở dữ liệu? Tôi nên nghĩ rằng tải / ghi gây ra sự phân mảnh trong bộ lưu trữ.

Hay nói chung hơn: các thực tiễn tốt nhất để duy trì triển khai sản xuất Cassandra là gì? Những gì phải được thực hiện trong khoảng thời gian thường xuyên để duy trì sức khỏe của hệ thống? Hướng dẫn vận hành thực sự không thảo luận về khía cạnh này.

Cảm ơn.

Nói chung, một cụm được thiết kế tốt có thể sống trong NĂM mà không bị chạm vào. Tôi đã có các cụm chạy trong nhiều năm. Tuy nhiên, đây là một số hướng dẫn:

Giám sát là vô cùng quan trọng:

1) Theo dõi độ trễ. Sử dụng opscenter hoặc các công cụ số liệu yêu thích của bạn để theo dõi độ trễ. Độ trễ tăng lên có thể là dấu hiệu của các vấn đề sắp xảy ra, bao gồm tạm dừng GC (phổ biến hơn trong khối lượng công việc đọc so với khối lượng công việc ghi), các vấn đề ổn định và tương tự.

2) Theo dõi số lượng ổn định. Số lượng SSTable sẽ tăng nếu bạn vượt quá độ nén (mỗi độ ổn định được viết chính xác một lần - việc xóa được xử lý bằng cách kết hợp các sstables cũ vào sstables mới thông qua nén).

3) Theo dõi sự thay đổi trạng thái nút (lên / xuống, v.v.). Nếu bạn thấy các nút vỗ, hãy điều tra, vì nó không bình thường.

4) Theo dõi việc sử dụng đĩa của bạn - theo truyền thống, bạn cần duy trì dưới 50% (đặc biệt nếu bạn sử dụng nén STCS).

Có một số điều cơ bản bạn nên và không nên làm thường xuyên:

1) Đừng chạy một cách rõ ràng nodetool compact. Bạn đề cập rằng bạn đã thực hiện nó, nó không gây tử vong, nhưng nó tạo ra các vật thể rất lớn, sau đó ít có khả năng tham gia vào quá trình nén tiến về phía trước. Bạn không nhất thiết phải tiếp tục chạy nó, nhưng đôi khi nó có thể giúp loại bỏ dữ liệu bị xóa / ghi đè.

2) nodetool repairthường được đề xuất mỗi gc_grace_seconds(10 ngày theo mặc định). Có các khối lượng công việc mà điều này ít quan trọng hơn - lý do lớn nhất mà bạn CẦN sửa chữa là để đảm bảo các dấu xóa ( tombstones) được truyền đi trước khi chúng hết hạn (chúng tồn tại gc_grace_seconds, nếu một nút bị hỏng khi xóa xảy ra, dữ liệu đó có thể hoạt động trở lại không cần sửa chữa!). Nếu bạn không đưa ra các thao tác xóa và bạn truy vấn với mức độ nhất quán đủ (ví dụ đọc và viết tại QUORUM), bạn thực sự có thể sống một cuộc sống mà không cần sửa chữa.

3) Nếu bạn định sửa chữa, hãy cân nhắc sử dụng sửa chữa gia tăng và sửa chữa các phạm vi nhỏ tại một thời điểm.

4) Chiến lược đầm nén quan trọng - rất nhiều. STCS là tuyệt vời để viết, LCS là tuyệt vời để đọc. DTCS có một số quirks.

5) Vấn đề về mô hình dữ liệu - giống như môi trường RDBMS / SQL gặp rắc rối khi các truy vấn không được thực hiện đánh vào các bảng lớn, Cassandra có thể gặp vấn đề với các hàng / phân vùng rất lớn.

6) Ảnh chụp nhanh là giá rẻ. Rất rẻ. Gần như ngay lập tức, chỉ cần liên kết cứng, chúng gần như không có dung lượng đĩa ngay lập tức. Sử dụng ảnh chụp trước khi bạn nâng cấp các phiên bản, đặc biệt là các phiên bản chính.

7) Cẩn thận với việc xóa. Như được gợi ý trong mục số 2, xóa sẽ tạo thêm dữ liệu trên đĩa và không giải phóng nó cho AT LEAST gc_grace_seconds.

Khi thất bại:

Tôi đã thấy các bài viết đề xuất Cassandra trong prod yêu cầu một đầu chuyên dụng để quản lý bất kỳ cụm có kích thước nào - Tôi không biết rằng điều đó nhất thiết phải đúng, nhưng nếu bạn lo lắng, bạn có thể muốn thuê một nhà tư vấn bên thứ ba (TheLastPickle, Pythian ) hoặc có hợp đồng hỗ trợ (Datastax) để bạn yên tâm.

Theo tài liệu sửa chữa Cassandra , nodetool repairnên được chạy trong các tình huống sau:

• Là một thực hành tốt nhất, bạn nên lên lịch sửa chữa hàng tuần. Lưu ý: Nếu việc xóa không bao giờ xảy ra, bạn vẫn nên lên lịch sửa chữa thường xuyên. Xin lưu ý rằng việc đặt một cột thành null là xóa.
• Trong quá trình phục hồi nút. Ví dụ, khi đưa một nút trở lại cụm sau khi thất bại.
• Trên các nút chứa dữ liệu không được đọc thường xuyên.
• Để cập nhật dữ liệu trên một nút đã bị hỏng.

Tôi nên nghĩ rằng tải / ghi gây ra sự phân mảnh trong bộ lưu trữ.

Dữ liệu trong Cassandra không "phân mảnh" theo cách bạn đang nghĩ. Tuy nhiên, việc xóa sẽ kích hoạt vị trí của bia mộ và quá trình thu gọn thông thường sẽ loại bỏ các bia mộ.

Bây giờ tôi hiểu rằng việc nén là một vấn đề lớn và chạy tự động

Chính xác. Tôi được một đại diện của DataStax nói rằng một khi bạn chạy compactthủ công, bạn sẽ luôn phải chạy thủ công. Lý do là việc nén hoạt động bằng cách "nén" tất cả các SSTABLES hiện có trong một không gian khóa thành một tệp SSTABLE duy nhất. Bạn có thể có một số họ cột trong tệp SSTABLE đó nhỏ và sẽ mất nhiều thời gian để tăng vượt ngưỡng nén, nên khả năng nén tự động từng chạy lại là rất thấp.

Về cơ bản, đảm bảo lên lịch trình thường xuyên nodetool repair, không bao giờ chạy nodetool compactvà thực hiện chiến lược sao lưu (ảnh chụp nhanh, sao lưu gia tăng hoặc cả hai).