การตรวจเช็กที่จำเป็นเพื่อให้ฐานข้อมูล MongoDB แข็งแรง

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

เราสามารถจัดหมวดหมู่สุขภาพของคลัสเตอร์ MongoDB ของคุณออกได้เป็น 3 ด้านพื้นฐาน:

• การทำซ้ำ (Replication)
• ประสิทธิภาพ (Performance)
• การสำรองข้อมูล (Backup) 

การประเมินด้านเหล่านี้เป็นประจำช่วยให้แพลตฟอร์มข้อมูลมีความแข็งแกร่งและเชื่อถือได้ ยิ่งไปกว่านั้น เครื่องมือจัดการสมัยใหม่อย่าง MongoDB Atlas และ MongoDB Ops Manager มีการมอนิเตอร์แบบบูรณาการพร้อมการแจ้งเตือนและคำแนะนำเพื่อช่วยให้ล่วงหน้ากว่าปัญหาที่อาจเกิดขึ้น การตั้งค่าแจ้งเตือนจะช่วยให้ติดตามสถานการณ์ได้ทัน คุณสามารถดูคำแนะนำและตัวอย่างเกี่ยวกับวิธีตั้งค่าแจ้งเตือนในเอกสารทางการของ MongoDBได้

มาดูแต่ละด้านกัน

สถานะการทำซ้ำ (Replication Status)

การทำซ้ำคือกระดูกสันหลังของความพร้อมใช้งานสูงใน MongoDB ชุดจำลอง (replica set) ที่แข็งแรงช่วยให้มีการทำซ้ำข้อมูลและความสามารถในการสลับตัวหลักเมื่อเกิดความขัดข้อง มาดูตัวชี้วัดสำคัญ 3 ประการเพื่อให้แน่ใจว่าการทำซ้ำระหว่างเซิร์ฟเวอร์ที่เป็นสมาชิกของชุดจำลองมีประสิทธิภาพ

ภาพรวมสถานะและรายละเอียดของการทำซ้ำ 

สามารถดูสถานะครบถ้วนของชุดจำลองได้โดยรันคำสั่ง rs.status() ในเชลล์ของ MongoDB คำสั่งนี้ให้ภาพรวมสถานะปัจจุบันของชุดจำลองอย่างครบถ้วน ควรตรวจสอบผลลัพธ์เพื่อยืนยันว่าสมาชิกทั้งหมดอยู่ในสภาพดี (เช่น อยู่ในสถานะ PRIMARY หรือ SECONDARY) และทำงานเป็นไปตามที่คาดหมาย

จาก Atlas UI ก็สามารถเข้าถึงข้อมูลที่คล้ายกับคำสั่งข้างต้นได้เช่นกัน จากหน้า "Clusters" คลิกชื่อคลัสเตอร์ที่ต้องการ จากนั้นจะไปที่แท็บ "Overview" ซึ่งจะแสดงภาพรวมของโหนด หากมีสิ่งใดผิดปกติอย่างชัดเจน ก็ควรจะแสดงให้เห็นที่นั่น 

เวลาในการทำซ้ำ

ความทนทานในคลัสเตอร์ที่ทำซ้ำขึ้นอยู่กับการทำซ้ำข้อมูลไปยังโหนดส่วนใหญ่ ดังนั้นคลัสเตอร์ที่แข็งแรงจึงต้องทำซ้ำได้รวดเร็ว หากไม่เป็นเช่นนั้น การปฏิบัติการที่ใช้majority write concern จะมีเวลาแฝงที่นานขึ้น

ตัวชี้วัดนำของลักษณะนี้คือ replication lag ซึ่งหมายถึงความล่าช้าระหว่างการปฏิบัติการบนสมาชิกตัวหลัก (primary) กับการนำไปใช้บนสมาชิกตัวรอง (secondary) ค่า replication lag ที่ต่ำและสม่ำเสมอเป็นสัญญาณที่ชัดเจนของสุขภาพที่ดี ในทางกลับกัน การทำซ้ำที่ช้าอาจบ่งบอกว่าการเชื่อมต่อระหว่างโหนดถูกกำหนดค่ามาไม่ดี

วิธีที่ง่ายที่สุดในการสังเกต replica lag คือดูที่กราฟ "Replication Lag" ภายใต้แท็บ "Cluster Metrics" นี่คือตัวอย่างกราฟสำหรับคลัสเตอร์ที่แข็งแรง โปรดทราบว่าค่านี้ไม่ใช้กับโหนด PRIMARY ของคลัสเตอร์ ซึ่งอยู่ตรงกลางและมีสัญลักษณ์ "P"

Replication Oplog Window 

การทำซ้ำถูกทำงานผ่านคอลเลกชันพิเศษที่เรียกว่า "oplog" โดย oplog (operation log) คือcapped collection ที่บันทึกปฏิบัติการที่แก้ไขข้อมูลทั้งหมด "Replication Oplog Window" หมายถึงเวลาประมาณการที่มีอยู่ใน oplog สำหรับแหล่งซิงก์ ก่อนที่ปฏิบัติการปัจจุบันจะเริ่มถูกเขียนทับ กล่าวอีกนัยหนึ่ง Replication Oplog Window คือความต่างของเวลา (timestamp) ที่ใหม่ที่สุดกับเก่าที่สุดใน oplog ค่าหน้าต่าง oplog ที่เพียงพอมีความสำคัญอย่างยิ่งเพื่อให้ secondary ไล่ทันหลังจากดับชั่วคราว และหลีกเลี่ยงความจำเป็นต้องซิงก์ข้อมูลใหม่ทั้งก้อน

หาก secondary ออฟไลน์นานกว่าค่า Replication Oplog Window ที่มีอยู่ จะต้องซิงก์ secondary ใหม่ตั้งแต่ต้น กล่าวคือ คุณต้องการค่า Replication Oplog Window ที่ยาวกว่าระยะเวลาสูงสุดที่เรพลิกาอาจใช้งานไม่ได้ โปรดทราบว่าค่านี้ไวต่อปริมาณงานเขียนที่พุ่งสูงเป็นช่วงๆ

สามารถเพิ่มขนาดของคอลเลกชัน oplog เพื่อให้ได้ Replication Oplog Window ที่ยาวขึ้น

สถานะประสิทธิภาพ (Performance Status)

ประสิทธิภาพส่งผลโดยตรงต่อประสบการณ์ผู้ใช้งานของแอปพลิเคชันและต้นทุนในการใช้งานคลัสเตอร์ คลัสเตอร์ที่แข็งแรงคือคลัสเตอร์ที่ทำงานได้อย่างมีประสิทธิภาพตามลักษณะงานของตน

ในส่วนนี้ มาดูแง่มุมสำคัญของประสิทธิภาพที่ควรมอนิเตอร์

จำนวนปฏิบัติการปัจจุบันเป็นไปตามที่คาดหวัง 

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

ติดตามอัตราปฏิบัติการ (อ่าน เขียน คำสั่ง) อย่างใกล้ชิด การพุ่งขึ้นหรือตกลงอย่างกะทันหันโดยไม่คาดคิดอาจบ่งชี้ปัญหา เช่น ปัญหาแอปพลิเคชัน คอขวดของทรัพยากร หรือรูปแบบคิวรีที่ไม่มีประสิทธิภาพ เพื่อช่วยเหลือ ให้ตั้งค่าแจ้งเตือนบนจำนวนปฏิบัติการ ซึ่งดูได้ในส่วน "Opcounters" ของ cluster metrics

นอกจากนี้ สามารถดูข้อมูลเรียลไทม์เกี่ยวกับอัตราปฏิบัติการปัจจุบันได้ผ่าน "Real Time Tab"

ทำความเข้าใจเชิงลึกเกี่ยวกับคิวรีที่ช้า 

คิวรีที่ใช้เวลานานผิดปกติเรียกว่า slow queries ซึ่งมักบ่งชี้ถึงความจำเป็นในการทำดัชนีหรือปรับแต่งคิวรี นอกจากนี้ การมอนิเตอร์ปฏิบัติการที่ต้องมีการจัดเรียงในหน่วยความจำก็สำคัญ เพราะอาจใช้ทรัพยากรของเซิร์ฟเวอร์มหาศาลและทำให้ประสิทธิภาพลดลง

แท็บ "Query Insights" ช่วยให้ดูคิวรี กรองตามเงื่อนไข และทำการดำเนินการเพิ่มเติม ใช้หน้านี้เพื่อระบุว่าคิวรีใดควรถูกปรับแต่ง และคิวรีใดอาจต้องไปรันบนโหนดอื่นหรือเลื่อนไปทำในเวลาถัดไป

ดัชนีที่ขาดหาย

สาเหตุที่พบบ่อยที่สุดของคิวรีที่ช้าใน MongoDB คือการไม่มีดัชนีที่เหมาะสม MongoDB สามารถสแกนทั้งคอลเลกชัน (ตรวจทุกเอกสารในคอลเลกชัน) เมื่อไม่มีดัชนี แต่นี่เป็นการทำงานที่ไม่มีประสิทธิภาพมาก โดยเฉพาะอย่างยิ่งกับคอลเลกชันขนาดใหญ่ การระบุและสร้างดัชนีที่ขาดหายเป็นสิ่งจำเป็นเพื่อคงประสิทธิภาพของคิวรี

แท็บ "Performance Advisor" มีเครื่องมือที่มีประโยชน์หลายอย่างเพื่อช่วยปรับแต่งประสิทธิภาพ ด้านล่างคือหน้า "Create Indexes"

สถานะการสำรองข้อมูล (Backup Status)

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

เช่นเดียวกับส่วนอื่นๆ มาดูข้อควรพิจารณาสำคัญสำหรับกลยุทธ์การสำรองข้อมูลของคุณ

กำหนดเป้าหมายการกู้คืน 

กำหนด Recovery Point Objective (RPO) ซึ่งคือปริมาณการสูญเสียข้อมูลสูงสุดที่ยอมรับได้ และ Recovery Time Objective (RTO) ซึ่งคือเวลาสูงสุดที่อนุญาตให้กู้คืนบริการ เป้าหมายเหล่านี้จะกำหนดความถี่และวิธีการสำรองข้อมูลที่ต้องใช้

พื้นฐานของการสำรองข้อมูล

มีเครื่องมือหลายอย่างสำหรับสำรองข้อมูลใน MongoDB เริ่มจากการดัมป์ข้อมูลอย่างง่ายด้วยmongodump แล้วต่อยอดไปใช้เครื่องมือจัดการของ MongoDB เพื่อทำสแนปชอตและเก็บปฏิบัติการทีละรายการ (oplog) เพื่อสร้างภาพในช่วงเวลาใดๆ MongoDB Atlas รวมเครื่องมือเหล่านี้ไว้สำหรับคลัสเตอร์ที่โฮสต์ไว้ ส่วน MongoDB OpsManager ทำหน้าที่คล้ายกันสำหรับคลัสเตอร์ภายในองค์กร

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

การติดตาม การเข้าถึง และการกู้คืนแบ็กอัพ

หากใช้ MongoDB Atlas ให้ตรวจสอบว่ากระบวนการสำรองข้อมูลแบบจัดการทำงานสำเร็จ จับสแนปชอตเป็นประจำ และนโยบายการเก็บรักษาสอดคล้องกับ RPO

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

สรุป

คลัสเตอร์ MongoDB ที่แข็งแรงมีลักษณะดังนี้:

• สถานะการทำซ้ำที่เหมาะสม
• ประสิทธิภาพที่มีประสิทธิผล
• การสำรองข้อมูลที่เชื่อถือได้

การมอนิเตอร์เชิงรุกในทั้งสามด้านนี้ การวิเคราะห์ประสิทธิภาพของคิวรี และการทดสอบการกู้คืน จะช่วยให้การปรับใช้ MongoDB มีเสถียรภาพและยั่งยืน