Secara umum, cluster yang dirancang dengan baik dapat hidup selama bertahun-tahun tanpa disentuh. Saya sudah memiliki kelompok yang berjalan selama bertahun-tahun lepas tangan. Namun, berikut beberapa pedoman:
Pemantauan sangat penting:
1) Memantau latensi. Gunakan opscenter atau alat metrik favorit Anda untuk melacak latensi. Latensi yang naik dapat menjadi tanda masalah yang datang, termasuk jeda GC (lebih umum pada beban kerja baca daripada beban kerja tulis), masalah stabil, dan sejenisnya.
2) Monitor jumlah yang stabil. Hitungan SSTable akan meningkat jika Anda overrun pemadatan (setiap sstable ditulis tepat satu kali - penghapusan ditangani dengan menggabungkan sstable lama ke sstable baru melalui pemadatan).
3) Monitor perubahan status simpul (atas / bawah, dll). Jika Anda melihat node mengepak, selidiki, karena itu tidak normal.
4) Melacak penggunaan disk Anda - secara tradisional, Anda harus tetap di bawah 50% (terutama jika Anda menggunakan pemadatan STCS).
Ada beberapa hal dasar yang harus dan tidak seharusnya Anda lakukan secara teratur:
1) Jangan lari secara eksplisit nodetool compact
. Anda menyebutkan bahwa Anda telah melakukannya, itu tidak fatal, tetapi hal itu menciptakan sstables yang sangat besar, yang kemudian cenderung berpartisipasi dalam pemadatan bergerak maju. Anda tidak perlu terus menjalankannya, tetapi kadang-kadang mungkin membantu untuk menyingkirkan data yang dihapus / ditimpa.
2) nodetool repair
biasanya direkomendasikan setiap gc_grace_seconds
(10 hari secara default). Ada beban kerja di mana ini kurang penting - alasan terbesar Anda MEMBUTUHKAN perbaikan adalah untuk memastikan penanda penghapusan ( tombstones
) ditransmisikan sebelum habis masa berlakunya (mereka hidup gc_grace_seconds
, jika sebuah simpul turun saat penghapusan terjadi, data dapat hidup kembali. tanpa perbaikan!). Jika Anda tidak mengeluarkan penghapusan, dan Anda kueri dengan tingkat konsistensi yang cukup (baca dan tulis di QUORUM, misalnya), Anda sebenarnya dapat menjalani kehidupan tanpa perbaikan.
3) Jika Anda akan memperbaiki, pertimbangkan untuk menggunakan perbaikan tambahan, dan memperbaiki rentang kecil sekaligus.
4) Strategi pemadatan penting - banyak. STCS bagus untuk menulis, LCS bagus untuk membaca. DTCS memiliki beberapa kebiasaan.
5) Model data penting - seperti lingkungan RDBMS / SQL yang bermasalah ketika kueri yang tidak diindeks menghantam tabel besar, Cassandra dapat bermasalah dengan baris / partisi yang sangat besar.
6) Snapshots murah. Sangat murah. Hampir instan, hanya tautan keras, harganya hampir tidak ada ruang disk segera. Gunakan snapshot sebelum Anda meningkatkan versi, terutama versi utama.
7) Hati-hati dengan penghapusan. Seperti yang diisyaratkan di # 2, delete membuat lebih banyak data pada disk, dan tidak membebaskannya sesekali gc_grace_seconds
.
Ketika semuanya gagal:
Saya telah melihat artikel yang menyarankan Cassandra di prod memerlukan kepala yang berdedikasi untuk mengelola setiap cluster berukuran - Saya tidak tahu bahwa itu benar, tetapi jika Anda khawatir, Anda mungkin ingin menyewa konsultan pihak ketiga (TheLastPickle, Pythian ) atau memiliki kontrak dukungan (Datastax) untuk memberi Anda ketenangan pikiran.