โดยทั่วไปคลัสเตอร์ที่ได้รับการออกแบบมาอย่างดีสามารถมีชีวิตอยู่ได้นานหลายปีโดยไม่ต้องสัมผัส ฉันมีกลุ่มที่วิ่งมาหลายปีแล้ว อย่างไรก็ตามนี่คือแนวทางบางส่วน:
การตรวจสอบมีความสำคัญอย่างมาก:
1) ตรวจสอบเวลาแฝง ใช้ opscenter หรือเครื่องมือวัดที่คุณชื่นชอบเพื่อติดตามเวลาแฝง เวลาแฝงที่เพิ่มขึ้นอาจเป็นสัญญาณของปัญหาที่กำลังจะเกิดขึ้นรวมถึงการหยุด GC ชั่วคราว (พบมากในการอ่านเวิร์กโหลดมากกว่าการเขียนเวิร์กโหลด) ปัญหาที่ไม่แน่นอนและอื่น ๆ
2) ตรวจสอบการนับ sstable การนับ SSTable จะเพิ่มขึ้นหากคุณใช้งานการบีบอัดมากเกินไป (แต่ละ sstable ถูกเขียนอย่างแน่นอนในครั้งเดียว - การลบจะได้รับการจัดการโดยการรวม sstables เก่าเป็น sstables ใหม่ผ่านการบดอัด)
3) ตรวจสอบการเปลี่ยนแปลงสถานะโหนด (ขึ้น / ลง ฯลฯ ) หากคุณเห็นโหนโหนให้ตรวจสอบเนื่องจากไม่เป็นปกติ
4) ติดตามการใช้งานดิสก์ของคุณ - โดยทั่วไปคุณต้องอยู่ต่ำกว่า 50% (โดยเฉพาะถ้าคุณใช้การบดอัด STCS)
มีสิ่งพื้นฐานบางอย่างที่คุณควรทำและไม่ควรทำเป็นประจำ:
1) nodetool compactไม่ได้เรียกใช้อย่างชัดเจน คุณพูดถึงว่าคุณทำไปแล้วมันไม่ได้ร้ายแรง แต่มันสร้าง sstables ที่มีขนาดใหญ่มากซึ่งจากนั้นมีโอกาสน้อยกว่าที่จะมีส่วนร่วมในการบดอัดก้าวไปข้างหน้า คุณไม่จำเป็นต้องใช้งานต่อไป แต่บางครั้งมันอาจช่วยกำจัดข้อมูลที่ถูกลบ / เขียนทับได้
2) nodetool repairแนะนำโดยทั่วไปทุก ๆgc_grace_seconds10 วันโดยค่าเริ่มต้น มีภาระงานที่นี่มีความสำคัญน้อยกว่า - เหตุผลที่ดีที่สุดที่คุณต้องการการซ่อมแซมคือการทำให้แน่ใจว่าเครื่องหมายการลบ ( tombstones) ถูกส่งก่อนที่มันจะหมดอายุ (พวกมันอาศัยอยู่gc_grace_secondsหากโหนดหยุดทำงานเมื่อการลบเกิดขึ้นข้อมูลนั้นอาจกลับมามีชีวิต โดยไม่ต้องซ่อม!) หากคุณไม่ออกการลบและคุณค้นหาด้วยระดับความสอดคล้องที่เพียงพอ (เช่นอ่านและเขียนที่ QUORUM เป็นต้น) คุณสามารถใช้ชีวิตได้โดยไม่ต้องซ่อม
3) หากคุณกำลังจะทำการซ่อมแซมให้พิจารณาใช้การซ่อมแซมแบบเพิ่มเติมและซ่อมแซมช่วงละน้อย ๆ
4) กลยุทธ์การบดอัดมีความสำคัญมาก STCS ยอดเยี่ยมสำหรับการเขียน LCS เหมาะสำหรับการอ่าน DTCS มีนิสัยใจคอ
5) ตัวแบบข้อมูลมีความสำคัญเช่นเดียวกับสภาพแวดล้อมของ RDBMS / SQL ที่พบเจอกับปัญหาเนื่องจากคิวรี่ที่ไม่ได้สร้างดัชนีขนาดใหญ่ Cassandra อาจมีปัญหากับแถว / พาร์ติชันที่มีขนาดใหญ่มาก
6) ภาพรวมมีราคาถูก ถูกมาก. เกือบจะทันทีลิงก์ยากเพียงแค่พวกเขาเสียค่าใช้จ่ายเกือบจะไม่มีพื้นที่ว่างในดิสก์ทันที ใช้สแน็ปช็อตก่อนที่คุณจะอัพเกรดรุ่นโดยเฉพาะรุ่นหลัก
7) ระวังด้วยการลบ ในฐานะที่เป็นนัยใน # 2 gc_grace_secondsลบสร้างข้อมูลเพิ่มเติมเกี่ยวกับดิสก์และไม่เป็นอิสระอย่างน้อย
เมื่อทุกอย่างล้มเหลว:
ฉันเคยเห็นบทความที่แนะนำ Cassandra ใน prod ต้องมีหัวหน้าที่ทุ่มเทในการจัดการคลัสเตอร์ขนาดใด ๆ - ฉันไม่รู้ว่ามันจำเป็นจริง แต่ถ้าคุณเป็นห่วงคุณอาจต้องการจ้างที่ปรึกษาบุคคลที่สาม (TheLastPickle, Pythian ) หรือมีสัญญาการสนับสนุน (Datastax) เพื่อให้คุณสบายใจ