Memahami Hinted Handoff dan Replikasi Data di Cassandra

Kami memiliki cluster Cassandra 3 node dengan RF = 2. Konsistensi baca dan tulis diatur ke SATU. Kami juga menggunakan Vnodes. Mari beri label node ini sebagai N1, N2 dan N3. Katakanlah N3 turun. Saya mendapat kesan bahwa setiap kali sebuah node mati, node lain akan menyimpan petunjuk dan setiap kali N3 muncul, petunjuk tersebut akan dikirim ke N3, sehingga memastikan bahwa data konsisten di seluruh replika. Namun, saat saya membaca dokumen, saya menemukan parameter max_hint_window_in_ms yang defaultnya adalah 3 jam. Jadi, jika sebuah node mati lebih dari 3 jam, maka dianggap mati permanen dan tidak ada petunjuk yang disimpan. Sejauh ini bagus.

Jadi, pemahaman saya sekarang adalah jika sebuah node mati misalnya selama 10 jam, maka petunjuk untuk 3 jam pertama akan ditransfer ke node ini ketika muncul kembali, tetapi penulisan untuk durasi 7 jam ini akan hilang selama ini. simpul. Selain itu, jika kueri baca diaktifkan untuk rentang token tertentu, dan karena node ini juga memenuhi syarat untuk melayani permintaan baca untuk rentang token, node tersebut akan mengembalikan null, bukan data aktual yang disimpan di beberapa node lain. Apakah pemahaman saya benar? Lalu apa yang harus dilakukan?


person Ranjeet Ranjan    schedule 30.05.2017    source sumber
comment
Apakah ini sedang diuji dan perilakunya tidak terduga? Atau apakah Anda mencari perilaku yang diharapkan jika skenario itu terjadi? Karena tingkat konsistensi Anda disetel ke SATU, semua baca/tulis harus berhasil (dengan asumsi throughput tidak besar).   -  person daniel    schedule 30.05.2017
comment
Saya mencoba mengevaluasi perilaku apa yang akan terjadi jika salah satu node saya mati selama lebih dari 3 jam (nilai default max_hint_window_in_ms).   -  person Ankush92    schedule 30.05.2017


Jawaban (1)


Lalu apa yang harus dilakukan?

Dokumen menyatakan bahwa ketika Anda mengembalikan node yang rusak (N3), Anda harus menjalankan perbaikan pada node tersebut.

Sejujurnya, di sebagian besar cluster kami, saya merasa lebih mudah untuk menghapus node (saat sedang down) dan kemudian mem-boot ulangnya ke dalam cluster. Hal ini biasanya berjalan lebih cepat dibandingkan komputasi pohon Merkle dan streaming data perbaikan. Namun jika Anda tidak memiliki banyak data per node (katakanlah kurang dari 20 GB), menjalankan perbaikan tidak akan terlalu merepotkan.

person Aaron    schedule 30.05.2017
comment
Saya kira Anda benar. Kami memiliki sekitar 100 GB data per node, tumbuh dengan kecepatan sekitar 5-10 GB setiap hari. Perbaikannya cukup menyakitkan. Harus meninggalkannya semalaman. Namun karena petunjuk penyerahan adalah bagian dari proses perbaikan, dan hanya disimpan selama jangka waktu 3 jam (nilai default), bukankah kita masih akan kehilangan data untuk jangka waktu setelah 3 jam, bahkan setelah menjalankan perbaikan? - person Ankush92; 30.05.2017
comment
@ Ankush92 Tidak, RF=2 Anda memastikan bahwa setidaknya satu replika akan ditulis. Saat Anda memperbaiki/bootstrap, node target akan menggunakan replika tersebut untuk mengalirkan data ke sana. - person Aaron; 30.05.2017