แก้ไขข้อผิดพลาด “DB Error: DB Failure / Corruption” ในบันทึกกล่องจดหมายของ Zimbra: การวินิจฉัยและการกู้คืนอย่างปลอดภัย

ข้อความ “DB Error: DB Failure” ในบันทึกเหตุการณ์ของกล่องจดหมาย Zimbra เป็นเพียงอาการ ไม่ใช่การวินิจฉัยปัญหาอาจบ่งชี้ถึงฐานข้อมูลหยุดทำงาน การเชื่อมต่อล้มเหลว พื้นที่ดิสก์หมด การเชื่อมต่อมากเกินไป หรือความเสียหายของตารางหรือ InnoDB จริงๆ วิธีแก้ไขที่ปลอดภัยขึ้นอยู่กับบรรทัดบันทึกเหตุการณ์โดยรอบและเซิร์ฟเวอร์ที่ได้รับผลกระทบ เริ่มต้นด้วยการตรวจสอบแบบอ่านอย่างเดียว ป้องกันข้อมูล และอย่าเรียกใช้คำสั่งซ่อมแซมทั่วไปเพียงเพราะคำว่า “corruption” ปรากฏขึ้น

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

ข้อความ "DB failure in mailbox.log" หมายความว่าอย่างไรกันแน่?

ฐานข้อมูลกล่องจดหมายของ Zimbra จัดเก็บข้อมูลเมตาของกล่องจดหมาย เช่น โฟลเดอร์ แท็ก สถานะข้อความ และตัวชี้ไปยังไฟล์ข้อความ ดัชนีการค้นหาจะถูกจัดเก็บแยกต่างหาก และเนื้อหาข้อความจะถูกจัดเก็บไว้ในที่เก็บข้อความ ดังนั้น ข้อผิดพลาดของฐานข้อมูลจึงไม่ได้หมายความว่าไฟล์อีเมลทุกไฟล์เสียหายโดยอัตโนมัติ และข้อผิดพลาดของดัชนีเพียงอย่างเดียวก็ไม่ใช่หลักฐานยืนยันความเสียหายของฐานข้อมูล Zimbra อธิบายถึงที่เก็บข้อมูลแยกต่างหากเหล่านี้ในเอกสารอ้างอิงสถาปัตยกรรมเซิร์ฟเวอร์ ของ ตน

เบาะแสสำคัญมักจะเป็นข้อผิดพลาดของฐานข้อมูลที่ปรากฏอยู่ใกล้กับข้อผิดพลาดของกล่องจดหมาย โดยเฉพาะอย่างยิ่งใน บันทึก /opt/zimbra/log/mysql_error.logการแก้ไขปัญหาของ Zimbra ระบุว่าmailbox.logและmysql_error.logเป็นจุดเริ่มต้นที่มีประโยชน์ โดยzmmailboxd.outมีรายละเอียดเกี่ยวกับการเริ่มต้นบริการกล่องจดหมาย ดู ข้อมูลอ้างอิงการแก้ไขปัญหา บันทึกของ Zimbra

คุณควรทำอะไรก่อนลองแก้ไขปัญหา?

• บันทึกเวลาที่เกิดเหตุการณ์ครั้งแรก เขตเวลา ชื่อโฮสต์เซิร์ฟเวอร์ บัญชีที่ได้รับผลกระทบ และข้อความแสดงข้อผิดพลาดทั้งหมด รวมถึงบรรทัดใกล้เคียง ลบข้อมูลรหัสผ่าน เนื้อหาข้อความ และข้อมูลส่วนบุคคลออกก่อนที่จะแชร์บันทึก
• กำหนดขอบเขต: กล่องจดหมายเดียว กล่องจดหมายหลายกล่องในที่เก็บข้อมูลเดียว หรือผู้ใช้ในหลายที่เก็บข้อมูล ปัญหาที่เกิดขึ้นกับบัญชีเดียวไม่ถือเป็นเหตุผลเพียงพอที่จะรีสตาร์ทฐานข้อมูลทั้งคลัสเตอร์
• ตรวจสอบให้แน่ใจว่ามีข้อมูลสำรองที่ใช้งานได้ล่าสุด และระบุขั้นตอนการกู้คืนเฉพาะเวอร์ชัน หากเกิดข้อผิดพลาดซ้ำๆ หรือผู้ใช้ได้รับผลกระทบ ให้หลีกเลี่ยงการรีสตาร์ทและการเขียนข้อมูลซ้ำๆ จนกว่าจะเข้าใจสถานะของฐานข้อมูล
• ควรใช้ช่วงเวลาการบำรุงรักษาสำหรับการตรวจสอบที่สแกนตารางฐานข้อมูล แม้แต่การตรวจสอบความสมบูรณ์ก็อาจเพิ่มภาระการอ่าน/เขียน และทำให้บริการกล่องจดหมายช้าลงได้

จะวินิจฉัยโรคอย่างปลอดภัยได้อย่างไร?

1. ตรวจสอบสถานะการให้บริการ

บนเซิร์ฟเวอร์เมลบ็อกซ์ ให้เปลี่ยนไปใช้บัญชี Zimbra และตรวจสอบสถานะบริการ เรียกใช้คำสั่งโดยใช้บัญชีที่แสดงในแต่ละข้อความแจ้งเตือน อย่าคัดลอกสัญลักษณ์ข้อความแจ้งเตือน เช่น เป็น$ส่วนหนึ่งของคำสั่ง

su - zimbra
zmcontrol status

โปรดสังเกตว่าโปรแกรมเมลบ็อกซ์กำลังทำงานอยู่หรือไม่ และปัญหาที่รายงานนั้นเกิดขึ้นเฉพาะกับเซิร์ฟเวอร์เมลบ็อกซ์เครื่องใดเครื่องหนึ่งหรือไม่ การที่กระบวนการเมลบ็อกซ์หยุดทำงานนั้นไม่เพียงพอที่จะสรุปได้ว่าฐานข้อมูลเสียหาย หน้าการแก้ไขปัญหาเมลบ็อกซ์ของ Zimbra ยังแสดงสถานะบริการและการเข้าสู่ระบบ/การกำหนดค่าฐานข้อมูลเป็นการตรวจสอบแยกต่างหาก หน้าดังกล่าวถูกระบุว่าเป็นหน้าเก็บถาวร ดังนั้นโปรดใช้เป็นข้อมูลพื้นฐานและปฏิบัติตามเอกสารประกอบสำหรับเวอร์ชันของคุณ

2. เปรียบเทียบข้อมูลในกล่องจดหมายและฐานข้อมูลพร้อมกัน

อ่านข้อความในช่วงเวลาเดียวกันในบันทึกทั้งสองฉบับ ข้อผิดพลาดแรกในลำดับมักมีประโยชน์มากกว่าบรรทัดสุดท้ายที่ระบุว่า "ระบบล้มเหลว"

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

มองหาข้อความฐานข้อมูลที่เกี่ยวข้อง ชื่อฐานข้อมูลหรือชื่อกลุ่มกล่องจดหมาย การประทับเวลาซ้ำๆ ความล้มเหลวในการเริ่มต้นระบบ หรือข้อผิดพลาดของระบบปฏิบัติการที่ตรงกัน ให้ถือว่าวลีเหล่านี้เป็นเพียงเบาะแส ไม่ใช่วิธีแก้ไขอัตโนมัติ:

3. ตรวจสอบความจุของดิสก์และข้อผิดพลาดของระบบปฏิบัติการ

ข้อมูลหรือไฟล์บันทึกเต็ม, จำนวน inode หมด หรือระบบจัดเก็บข้อมูลล้มเหลว อาจทำให้ดูเหมือนว่าฐานข้อมูลล้มเหลว ให้ทำการตรวจสอบแบบไม่ทำลายข้อมูลบนโฮสต์ที่จัดเก็บข้อมูล:

df -h /opt/zimbra
df -i /opt/zimbra

ตรวจสอบบันทึกการทำงานของระบบปฏิบัติการหรือบันทึกระบบเพื่อหาข้อผิดพลาดเกี่ยวกับการอ่าน/เขียนดิสก์ ระบบไฟล์ หรือหน่วยความจำไม่เพียงพอในช่วงเวลาเดียวกัน หากไดรฟ์เต็ม ให้ลบหรือเพิ่มพื้นที่ว่างโดยใช้ขั้นตอนการจัดเก็บข้อมูลตามปกติของคุณ อย่าลบไฟล์ฐานข้อมูล บันทึก InnoDB หรือบันทึก Zimbra ที่ใช้งานอยู่เพื่อเพิ่มพื้นที่ว่าง เพราะอาจทำให้การกู้คืนทำได้ยากขึ้นหรือทำลายหลักฐานได้

4. ตรวจสอบความถูกต้องของข้อมูลหลังจากประเมินผลกระทบแล้วเท่านั้น

หากสามารถเข้าถึงบริการฐานข้อมูลของ Zimbra ได้ และบันทึกข้อมูลไม่ได้แสดงให้เห็นถึงปัญหาการเชื่อมต่อหรือปัญหาการจัดเก็บข้อมูลที่ชัดเจน ผู้ดูแลระบบสามารถพิจารณาใช้รายงานความสมบูรณ์มาตรฐานในช่วงเวลาการบำรุงรักษาที่มีปริมาณการใช้งานต่ำได้:

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

เอกสารอ้างอิงรายงานความสมบูรณ์ของ Zimbra อธิบายว่านี่คือการตรวจสอบฐานข้อมูลและเตือนว่าอาจเพิ่มการอ่าน/เขียนข้อมูล (I/O) และทำให้ความหน่วงของกล่องจดหมายเพิ่มขึ้น นอกจากนี้ยังระบุตัว-rเลือกในการพยายามซ่อมแซมตารางโดยอัตโนมัติ อย่าเพิ่ม-rเป็นขั้นตอนถัดไปตามปกติ: หน้านี้ถูกทำเครื่องหมายว่าอยู่ในระหว่างการพัฒนา และการดำเนินการที่ถูกต้องขึ้นอยู่กับเอ็นจิ้นฐานข้อมูล ประเภทตาราง รุ่นของผลิตภัณฑ์ และสถานะการสำรองข้อมูล รายงานที่กล่าวถึงเฉพาะข้อความการล็อกตารางบันทึกที่ไม่เป็นอันตราย ควรตีความตามหมายเหตุในหน้านั้น อย่าถือว่าส่วนหัว "พบข้อผิดพลาดของฐานข้อมูล" ทุกข้อความเหมือนกันหมด

วิธีแก้ไขใดที่ตรงกับหลักฐาน?

• บริการฐานข้อมูลหยุดทำงาน แต่ไม่พบหลักฐานความเสียหายใดๆ:ให้แก้ไขข้อผิดพลาดในการเริ่มต้น การกำหนดค่า ข้อมูลรับรอง หรือทรัพยากรที่เฉพาะเจาะจงก่อน เมื่อแก้ไขแล้ว ให้ใช้ขั้นตอนการกู้คืนบริการสำหรับโครงสร้างการเผยแพร่และการปรับใช้ของคุณ หลีกเลี่ยงการรีสตาร์ทโดยไม่ตรวจสอบซ้ำๆ
• การเชื่อมต่อมากเกินไป:ตรวจสอบภาระงาน ลูกค้าที่ค้างอยู่ และความจุของบริการ อย่าระบุว่าเป็นความเสียหายของฐานข้อมูล หรือคัดลอกคำแนะนำเก่าๆ ในการเพิ่มขีดจำกัดโดยไม่ตรวจสอบขนาดปัจจุบันและแนวทางการเผยแพร่ก่อน
• ปัญหาเกี่ยวกับดิสก์หรือระบบไฟล์:ทำให้พื้นที่จัดเก็บข้อมูลเสถียรและตรวจสอบว่าระบบไฟล์อยู่ในสภาพดี หากฐานข้อมูลบันทึกการเขียนที่ไม่สำเร็จหรือข้อผิดพลาด InnoDB ให้ถือว่านี่เป็นเหตุการณ์ที่อาจส่งผลกระทบต่อความสมบูรณ์ของข้อมูล แม้ว่าพื้นที่จัดเก็บข้อมูลจะได้รับการกู้คืนแล้วก็ตาม
• รายงานการตรวจสอบความสมบูรณ์ของข้อมูลแจ้งเตือนตารางที่มีปัญหา:ให้บันทึกผลลัพธ์ที่แน่นอน ชื่อตาราง/ฐานข้อมูล เวลา และบันทึกที่เกี่ยวข้อง สำรองข้อมูลหรือสร้างสแนปช็อตของวอลุ่มฐานข้อมูลโดยใช้วิธีการที่รองรับก่อนดำเนินการเขียนข้อมูลใดๆ ให้ผู้ดูแลระบบปฏิบัติตามขั้นตอนการซ่อมแซมหรือกู้คืนที่ผู้จำหน่ายให้การสนับสนุนสำหรับเวอร์ชัน Zimbra ที่ติดตั้งไว้
• แม้ว่าระบบฐานข้อมูลจะยังทำงานได้ปกติ แต่บัญชีผู้ใช้หนึ่งบัญชียังคงได้รับผลกระทบ โปรดตรวจสอบเมตาเดต้าของกล่องจดหมาย ที่เก็บข้อความ หรือดัชนีของบัญชีนั้นแยกต่างหาก หลีกเลี่ยงการแก้ไขแถว SQL ด้วยตนเองหรือการลบไฟล์เพื่อ "สร้างบัญชีใหม่"

สำหรับกรณีที่สงสัยว่า InnoDB เสียหาย วิธีการซ่อมแซมที่ปลอดภัยที่สุดมักจะเป็นการกู้คืนเฉพาะรุ่นจากข้อมูลสำรองที่ได้รับการตรวจสอบแล้ว หรือการกู้คืนโดยได้รับคำแนะนำจากฝ่ายสนับสนุน ไม่ใช่REPAIR TABLEการเริ่มต้นฐานข้อมูลใหม่แบบทั่วไป หรือการคัดลอกลำดับคำสั่ง บทความการกู้คืนในวิกิของ Zimbra บางบทความเก่าๆ มีขั้นตอนที่ทำให้ข้อมูลเสียหาย และถูกเก็บถาวรไว้อย่างชัดเจน ห้ามนำไปใช้กับระบบปัจจุบันโดยไม่ได้รับการยืนยันโดยตรงจากฝ่ายสนับสนุนของ Zimbra และข้อมูลสำรองที่ผ่านการทดสอบแล้ว

คุณจะยืนยันได้อย่างไรว่าปัญหาได้รับการแก้ไขแล้ว?

หลังจากดำเนินการแก้ไขที่ได้รับการอนุมัติแล้ว โปรดยืนยันว่าฐานข้อมูลและบริการกล่องจดหมายยังคงทำงานได้ รายการใหม่ที่เพิ่มเข้ามาไม่แสดงข้อผิดพลาดของฐานข้อมูลเดิมอีกต่อไป และบัญชีที่ได้รับผลกระทบสามารถดำเนินการอีเมลได้ตามปกติ เรียกใช้รายงานความสมบูรณ์มาตรฐานอีกครั้งเฉพาะเมื่อเหมาะสมกับช่วงเวลาการโหลดและเวอร์ชันของคุณเท่านั้น ยืนยันว่างานสำรองข้อมูลเสร็จสมบูรณ์และเก็บรักษาบันทึกและบันทึกการซ่อมแซมไว้ หากปัญหากลับมาอีก โปรดรายงานเวอร์ชัน/บิลด์ของ Zimbra ที่แน่นอน รูปแบบเซิร์ฟเวอร์เดี่ยวหรือหลายเซิร์ฟเวอร์ ขอบเขตกล่องจดหมาย เวลาที่เกิดความล้มเหลวครั้งแรก ส่วนของบันทึกที่เกี่ยวข้อง สถานะของดิสก์ เอาต์พุตของรายงานความสมบูรณ์ และการประทับเวลาของการสำรองข้อมูลไปยังผู้ดูแลระบบของคุณหรือช่องทางการสนับสนุนของ Zimbra

จุดสำคัญ:ตรวจสอบหาสาเหตุของข้อผิดพลาดในฐานข้อมูลที่อยู่เบื้องหลังข้อยกเว้นกล่องจดหมายก่อนที่จะเปลี่ยนแปลงข้อมูล ข้อความ "ฐานข้อมูลล้มเหลว" เพียงอย่างเดียวไม่สามารถบอกได้ว่าวิธีแก้ไขคือการแก้ไขข้อมูลรับรอง การเปลี่ยนแปลงความจุ การซ่อมแซมพื้นที่จัดเก็บ หรือการกู้คืนฐานข้อมูล

เอกสารอ้างอิงหลัก: ดัชนีเอกสาร Zimbra ; สถาปัตยกรรมเซิร์ฟเวอร์ Zimbra ; การแก้ไขปัญหาบันทึก Zimbra ; เอกสารอ้างอิงรายงานความสมบูรณ์ของฐานข้อมูล Zimbra ; เอกสารอ้างอิงข้อผิดพลาด MySQL 1040 ของ Zimbra ; และเอกสารอ้างอิงการแก้ไขปัญหาเมลบ็อกซ์ Zimbraบางหน้าในศูนย์เทคนิคถูกเก็บถาวรหรือระบุว่าอยู่ในระหว่างการพัฒนา ตามที่ระบุไว้ในบทความ