ส่วนนี้จะอธิบายงานบำรุงรักษาเป็นระยะสำหรับ Cassandra
การบำรุงรักษาแบบป้องกันข้อมูลย้อนกลับ
โหนดวงแหวน Apache Cassandra ต้องได้รับการบำรุงรักษาเป็นระยะเพื่อให้โหนดทั้งหมดสอดคล้องกัน หากต้องการดำเนินการบำรุงรักษานี้ ให้ใช้คำสั่งต่อไปนี้
apigee-service apigee-cassandra apigee_repair -pr
Apigee ขอแนะนําให้ทําดังนี้เมื่อเรียกใช้คําสั่งนี้
- ทำงานบนโหนด Cassandra ทุกโหนด (ในทุกภูมิภาคหรือศูนย์ข้อมูล)
เรียกใช้ทีละโหนดเพื่อให้แน่ใจว่าโหนดทั้งหมดในวงมีความสอดคล้องกัน การเรียกใช้งานซ่อมในโหนดหลายรายการพร้อมกันอาจส่งผลเสียต่อสถานะของ Cassandra
หากต้องการตรวจสอบว่างานซ่อมในโหนดเสร็จสมบูรณ์หรือไม่ ให้ดูรายการที่มี UUID ของเซสชันการซ่อมล่าสุดและวลี "เซสชันเสร็จสมบูรณ์" ในไฟล์
system.logของโหนด ตัวอย่างรายการบันทึกมีดังนี้INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully" Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
- เรียกใช้ในช่วงที่มีภาระงานค่อนข้างต่ำ (เครื่องมือจะสร้างภาระงานจำนวนมากให้กับระบบ)
- เรียกใช้อย่างน้อยทุก 7 วันเพื่อขจัดปัญหาที่เกี่ยวข้องกับ "การลบที่ลืม" ของ Cassandra
- เรียกใช้บนโหนดต่างๆ ในวันที่แตกต่างกัน หรือตั้งเวลาให้ห่างกันหลายชั่วโมงระหว่างการเรียกใช้ในแต่ละโหนด
- ใช้ตัวเลือก
-pr(ช่วงตัวแบ่งพาร์ติชัน) เพื่อระบุช่วงตัวแบ่งพาร์ติชันหลักของโหนดเท่านั้น
หากคุณเปิดใช้การตรวจสอบสิทธิ์ JMX สําหรับ Cassandra ต้องระบุชื่อผู้ใช้และรหัสผ่านเมื่อเรียกใช้ nodetool เช่น
apigee-service apigee-cassandra apigee_repair -u username -pw password -pr
นอกจากนี้ คุณยังเรียกใช้คําสั่งต่อไปนี้เพื่อตรวจสอบตัวเลือกที่รองรับของ apigee_repair: ได้ด้วย
apigee-service apigee-cassandra apigee_repair -h
หมายเหตุ: apigee_repair เป็นเครื่องมือสำหรับเรียกใช้การซ่อมของ nodetool ของ Cassandra ซึ่งจะดำเนินการตรวจสอบเพิ่มเติมก่อนที่จะทำการซ่อมของ Cassandra
ดูข้อมูลเพิ่มเติมได้ที่แหล่งข้อมูลต่อไปนี้
การบำรุงรักษาไฟล์บันทึก
บันทึก Cassandra จะจัดเก็บไว้ในไดเรกทอรี /opt/apigee/var/log/apigee-cassandra ของโหนดแต่ละโหนด โดยค่าเริ่มต้น ระบบจะสร้างไฟล์บันทึกได้สูงสุด 50 ไฟล์ โดยแต่ละไฟล์มีขนาดสูงสุด 20 MB เมื่อถึงขีดจํากัดนี้ ระบบจะลบบันทึกเก่าออกเมื่อสร้างบันทึกใหม่
หากพบว่าไฟล์บันทึกของ Cassandra ใช้พื้นที่มากเกินไป คุณสามารถแก้ไขปริมาณพื้นที่ที่จัดสรรสำหรับไฟล์บันทึกได้โดยแก้ไขการตั้งค่า log4j
- แก้ไข
/opt/apigee/customer/application/cassandra.propertiesเพื่อตั้งค่าพร็อพเพอร์ตี้ต่อไปนี้ หากไม่มีไฟล์ดังกล่าว ให้สร้างไฟล์ดังนี้conf_logback_maxfilesize=20MB # max file size conf_logback_maxbackupindex=50 # max open files
- รีสตาร์ท Cassandra โดยใช้คําสั่งต่อไปนี้
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
การดูแลรักษาพื้นที่ในดิสก์
คุณควรตรวจสอบการใช้งานดิสก์ของ Cassandra เป็นประจําเพื่อให้แน่ใจว่าแต่ละดิสก์มีพื้นที่ว่างอย่างน้อย 50 เปอร์เซ็นต์ หากการใช้งานดิสก์เพิ่มขึ้นเกิน 50 เปอร์เซ็นต์ เราขอแนะนำให้คุณเพิ่มพื้นที่ในดิสก์เพื่อลดเปอร์เซ็นต์ที่ใช้งานอยู่
Cassandra จะดำเนินการต่อไปนี้โดยอัตโนมัติเพื่อลดการใช้ดิสก์ของตัวเอง
- การลบโทเค็นการตรวจสอบสิทธิ์เมื่อโทเค็นหมดอายุ อย่างไรก็ตาม ระบบอาจใช้เวลา 2-3 สัปดาห์ในการเพิ่มพื้นที่ว่างในดิสก์ที่โทเค็นใช้อยู่ ทั้งนี้ขึ้นอยู่กับการกำหนดค่าของคุณ หากการลบอัตโนมัติไม่เพียงพอที่จะรักษาพื้นที่ในดิสก์ให้เพียงพอ โปรดติดต่อทีมสนับสนุนเพื่อดูข้อมูลเกี่ยวกับการลบโทเค็นด้วยตนเองเพื่อกู้คืนพื้นที่
หมายเหตุเกี่ยวกับการบีบอัดข้อมูล: ตั้งแต่ Edge for Private Cloud 4.51.00 เป็นต้นไป การติดตั้ง Apigee Cassandra ใหม่จะสร้างคีย์สเปซด้วย กลยุทธ์การบีบอัดแบบเป็นชั้น
การติดตั้ง Edge สำหรับ Private Cloud เวอร์ชันเก่าซึ่งอัปเกรดเป็น Private Cloud 4.51.00 จะยังคงใช้กลยุทธ์การบีบอัดก่อนหน้าต่อไป หากกลยุทธ์การบีบอัดที่มีอยู่คือ SizeTieredCompactionStrategy เราขอแนะนำให้เปลี่ยนเป็น LeveledCompactionStrategy ซึ่งจะใช้ประโยชน์จากดิสก์ได้ดียิ่งขึ้น
หมายเหตุ: เมื่อ Cassandra ทำการบีบอัดข้อมูล ระบบอาจใช้รอบของ CPU และหน่วยความจำเป็นจำนวนมาก แต่การใช้ทรัพยากรควรกลับมาเป็นปกติเมื่อการบีบอัดเสร็จสมบูรณ์
คุณสามารถเรียกใช้คำสั่ง 'Nodetool compactionstats' ในโหนดแต่ละโหนดเพื่อตรวจสอบว่าระบบกำลังทำการบีบอัดหรือไม่ เอาต์พุตของ compactionstats จะแจ้งให้คุณทราบหากมีการจัดเก็บข้อมูลรอดำเนินการและเวลาโดยประมาณที่ใช้ในการดำเนินการให้เสร็จสมบูรณ์