งานบำรุงรักษา Apache Cassandra

ส่วนนี้อธิบายถึงงานบำรุงรักษาเป็นระยะสำหรับ Cassandra

การบำรุงรักษาแบบต่อต้านเอนโทรปี

โหนดริงของ Apache Cassandra จำเป็นต้องมีการบำรุงรักษาเป็นระยะๆ เพื่อให้มั่นใจว่าโหนดทั้งหมดมีความสอดคล้องกัน ใช้คำสั่งต่อไปนี้เพื่อดำเนินการบำรุงรักษา

apigee-service apigee-cassandra apigee_repair -pr

Apigee ขอแนะนำสิ่งต่อไปนี้เมื่อเรียกใช้คำสั่งนี้

  • ทำงานบนโหนด Cassandra ทุกโหนด (ในทุกภูมิภาคหรือศูนย์ข้อมูล)

  • เรียกใช้บนโหนดทีละรายการเพื่อให้โหนดทั้งหมดในริงสอดคล้องกัน การเรียกใช้งานการซ่อมบนหลายโหนดพร้อมกันทำได้ สร้างความเสียหายต่อสุขภาพของคาสซานดรา

    หากต้องการตรวจสอบว่างานซ่อมแซมในโหนดเสร็จสมบูรณ์หรือไม่ ให้ดูในคอลัมน์ system.log ไฟล์สำหรับรายการ ด้วย UUID ของเซสชันการซ่อมล่าสุด และวลี "เซสชันเสร็จสมบูรณ์" ตัวอย่างรายการบันทึกมีดังนี้

    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 คือค่าที่ไม่ทำงานสำหรับการซ่อมแซมโหนดของ Cassandra ซึ่งจะดำเนินการตรวจสอบเพิ่มเติมก่อนซ่อมรถ Cassandra

สำหรับข้อมูลเพิ่มเติม โปรดดูแหล่งข้อมูลต่อไปนี้

การบำรุงรักษาไฟล์บันทึก

บันทึกของ Cassandra จะเก็บอยู่ในไดเรกทอรี /opt/apigee/var/log/cassandra บน แต่ละโหนด โดยค่าเริ่มต้น ไฟล์บันทึกสูงสุด 50 ไฟล์ โดยแต่ละไฟล์มีขนาดได้สูงสุด 20 MB สร้าง; เมื่อถึงขีดจำกัดนี้แล้ว บันทึกเก่าจะถูกลบเมื่อมีการสร้างบันทึกที่ใหม่กว่า

ถ้าคุณพบว่าไฟล์บันทึกของ Cassandra ใช้พื้นที่มากเกินไป คุณสามารถแก้ไข จำนวนพื้นที่ที่จัดสรรสำหรับไฟล์บันทึกโดยแก้ไขการตั้งค่า log4j

  1. แก้ไข/opt/apigee/customer/application/cassandra.properties เพื่อตั้งค่าพร็อพเพอร์ตี้ต่อไปนี้ หากไม่มีไฟล์อยู่ ให้สร้างไฟล์ดังกล่าวโดยทำดังนี้ 
    conf_logback_maxfilesize=20MB
# max file size
conf_logback_maxbackupindex=50 # max open files
  2. รีสตาร์ท Cassandra โดยใช้คำสั่งต่อไปนี้ 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

การบำรุงรักษาพื้นที่ในดิสก์

คุณควรตรวจสอบการใช้งานดิสก์ Cassandra เป็นประจำเพื่อให้แน่ใจว่า แต่ละดิสก์จะว่าง หากการใช้งานดิสก์สูงกว่า 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 จะแจ้งให้คุณทราบหากมี กำลังรอการดำเนินการบีบอัดและใช้เวลาโดยประมาณในการดำเนินการให้เสร็จสมบูรณ์