การมีฮาร์ดไดรฟ์เต็มรูปแบบในเซิร์ฟเวอร์ฐานข้อมูลที่มีปริมาณการใช้งานสูงหรือไม่

ใช้งานเซิร์ฟเวอร์ Ubuntu ด้วย MySQL สำหรับเซิร์ฟเวอร์ฐานข้อมูลการผลิตปริมาณสูง ไม่มีอะไรทำงานบนเครื่องยกเว้นอินสแตนซ์ MySQL

เราจัดเก็บการสำรองฐานข้อมูลรายวันบนเซิร์ฟเวอร์ฐานข้อมูลมีประสิทธิภาพหรือเหตุผลใดที่เราควรให้ฮาร์ดดิสก์ว่างเปล่า หากดิสก์เต็มไปด้วย 86% + กับฐานข้อมูลและการสำรองข้อมูลทั้งหมดมันจะส่งผลเสียต่อประสิทธิภาพหรือไม่?

ดังนั้นเซิร์ฟเวอร์ DB ที่ทำงานด้วยความจุเต็ม 86-90% + จะทำงานได้ดีกว่าเซิร์ฟเวอร์ที่ทำงานด้วยดิสก์เต็มเพียง 10% หรือไม่

ขนาดดิสก์ทั้งหมดบนเซิร์ฟเวอร์เกิน 1 TB ดังนั้นแม้ 10% ของดิสก์ควรจะเพียงพอสำหรับการแลกเปลี่ยน O / S พื้นฐานและเช่นนั้น

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

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

• ขอเวลา - ซึ่งเป็นเวลาที่ดิสก์ไดรฟ์ย้ายหัวดิสก์จากตำแหน่งแทร็กปัจจุบันไปยังแทร็กที่มีข้อมูลที่ร้องขอ

• เวลาในการตอบสนองการหมุน - ซึ่งเป็นเวลาเฉลี่ยสำหรับข้อมูลที่ต้องการในการเข้าถึงหัวอ่านเมื่อไดรฟ์หมุน - สำหรับไดรฟ์ 15K RPM นี่คือ 2 มิลลิวินาที (มิลลิวินาที)

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

ดังที่กล่าวไว้อย่างไรก็ตามหากไดรฟ์ของคุณเต็มและแอปพลิเคชันของคุณเข้าถึงเพียงเล็กน้อยของข้อมูลที่เก็บไว้ในไดรฟ์และข้อมูลทั้งหมดนี้อยู่ติดกับไดรฟ์ดังนั้น I / Os เหล่านี้จะได้รับผลกระทบน้อยที่สุด .

น่าเสียดายที่คำตอบสำหรับคำถามนี้คือ "ระยะทางของคุณจะแตกต่างกัน" ซึ่งหมายความว่าแอปพลิเคชันของคุณเข้าถึงข้อมูลและตำแหน่งของข้อมูลนั้นจะเป็นตัวกำหนดประสิทธิภาพของ I / O ของคุณ

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

มีสองมุมที่ต้องพิจารณาที่นี่: ประสิทธิภาพและความทนทาน

ประสิทธิภาพควรใช้โดยทั่วไปจะมีแกนหมุนดิสก์แยกต่างหาก (หรือกลุ่ม RAID / ชุดไดรฟ์) สำหรับ:

1. สิ่งต่าง ๆ ของระบบปฏิบัติการ (ไบนารีบันทึกบ้านไดเรกทอรี ฯลฯ )
2. พื้นที่สว็อป (ซึ่งอาจรวมกับ (1) หากคุณไม่คาดว่าจะใช้สว็อป)
3. ฐานข้อมูลการผลิต
4. บันทึกธุรกรรมของฐานข้อมูลการผลิต (ถ้าใช้)
5. ฐานข้อมูลทิ้ง / สำรองข้อมูล

เหตุผลที่อยู่เบื้องหลังนี้ค่อนข้างตรงไปตรงมา: คุณไม่ต้องการประสิทธิภาพของฐานข้อมูลที่ได้รับผลกระทบจาก "สิ่งอื่น ๆ " ที่ต้องการดิสก์ (เช่นถ้าเครื่องเริ่มทำการแลกเปลี่ยนอย่างหนักและพาร์ทิชัน swap อยู่อีกด้านหนึ่งของดิสก์จากข้อมูล DB ที่คุณ มีความยาวดิสก์ที่พยายามจะโต้แย้ง)

จากจุดยืนที่แข็งแกร่งคุณต้องการการแยกประเภทแบบเดียวกัน แต่ด้วยเหตุผลที่แตกต่าง: ตามที่คนอื่น ๆ ชี้ว่าคุณไม่ต้องการให้ดิสก์ที่ล้มเหลวนำออกทั้ง DB และการสำรองข้อมูลของคุณ (แม้ว่าจะเป็นจริงคุณควรคัดลอกข้อมูลสำรอง เซิร์ฟเวอร์ในกรณีที่เกิดความล้มเหลวอย่างรุนแรง)

คุณต้องการหลีกเลี่ยงการกำหนดค่าใด ๆ ด้วย/พาร์ติชันแบบเสาหินที่มีทุกสิ่ง - นี่เป็นความผิดพลาดที่โชคร้าย, น่าเศร้าและเป็นเรื่องธรรมดาที่เกิดขึ้นในโลก Linux ซึ่งไม่ได้ใช้ร่วมกับระบบ Unix อื่น ๆ
ดังที่ Gravyface กล่าวไว้ในความคิดเห็นของเขาหากคุณจัดการ/ระบบของคุณจนเต็มจะทำให้ระบบล่มและการล้าง / กู้คืนอาจใช้เวลานานและมีค่าใช้จ่ายสูงหากระบบมี/พาร์ติชันเดียวแทนที่จะเป็นลำดับชั้นที่มีโครงสร้างที่ดี

ฉันขอแนะนำให้ย้ายฐานข้อมูลและสำรองข้อมูลชั่วคราว (ดูด้านล่าง) ไปยังพาร์ติชันอื่นนอกเหนือจากรูท (/)

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

นั่นเป็นขั้นตอนการดำเนินงานมาตรฐานที่ค่อนข้างมาก

สิ่งนี้ทำให้ฉันนึกถึงข้อผิดพลาดใน NetApp ที่ซึ่งระบบไฟล์ที่ใกล้เต็มมีประสิทธิภาพลดลงอย่างมีนัยสำคัญ (เหมือนครึ่งหนึ่ง) (เป็นที่ยอมรับเมื่อไม่กี่ปีที่ผ่านมา)

คำตอบที่ทุกคนพูดขึ้นอยู่กับมัน แต่มันก็คุ้มค่าที่จะคิด

ข้อเสียเปรียบหลักของระบบไฟล์แบบเต็มคือรายการของ inodes ฟรีมีแนวโน้มที่จะแยกส่วนและทั่วทุกสถานที่

มีข้อมูลสามประเภทที่อยู่บนฮาร์ดดิสก์สำหรับฐานข้อมูล

1. ไฟล์ฐานข้อมูลจริงของคุณ นี่จะเป็นไฟล์ที่จัดสรรล่วงหน้าขนาดใหญ่ซึ่งโดยทั่วไปจะเติบโตเป็นกลุ่มก้อนขนาดใหญ่ (เช่น 10%)
2. Logs บันทึกการทำธุรกรรมของคุณที่ถูกเขียนอย่างต่อเนื่องลบเขียน ฯลฯ ...
3. ไฟล์ชั่วคราวสำหรับข้อความค้นหาขนาดใหญ่ที่ไม่สามารถเรียกใช้ในหน่วยความจำ

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

(2) การลบบันทึกที่ไร้เดียงสาซึ่งใช้ระบบปฏิบัติการเพื่อจัดการการจัดสรรพื้นที่และการลบทิ้งจะได้รับผลกระทบ สมมติว่าฐานข้อมูลของคุณไม่ได้อ่านอย่างเดียวจะมีการบันทึกสตรีมอย่างต่อเนื่อง แต่จะมีการแยกส่วนในพื้นที่ฮาร์ดดิสก์ที่ต่ำ ท้ายที่สุดสิ่งนี้จะส่งผลกระทบต่อประสิทธิภาพการเขียนของคุณ

(3) tempDB ถ้า DB ต้องการมันสำหรับการสืบค้นแบบ shoddy หรือ RAM ไม่เพียงพอคุณจะพบปัญหาที่ใหญ่กว่าพื้นที่ดิสก์เหลือน้อยที่ทำให้เกิดปัญหาประสิทธิภาพเนื่องจากแม้แต่ประสิทธิภาพการอ่านของคุณก็อาจกลายเป็นดิสก์ที่ถูกผูกไว้ คุณยังเสี่ยงต่อการเกิดไฟดับหาก MySql ต้องการจัดสรรพื้นที่ดิสก์สำหรับ tempDB และฮาร์ดดิสก์หมด

เกี่ยวกับการสำรองข้อมูล ...

1. องค์กรทุกแห่งที่ฉันทำงานเก็บการสำรองข้อมูลไว้ในเครื่องเดียวกัน เมื่อมันมาถึงการคืนค่า (ใครสนใจเกี่ยวกับการสำรองข้อมูลมันจะคืนค่าที่นับ) ไม่มีสิ่งใดจะเอาชนะความเร็วของการมีไฟล์ db อยู่ในดิสก์เดียวกัน
2. หวังอย่างชัดเจนว่าการสำรองข้อมูลไม่ได้อยู่ในเครื่อง

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

1. ยืนยันฉันมี RAM เพียงพอ
2. การแยกบันทึกและข้อมูลชั่วคราวทั้งหมดจากฐานข้อมูลของคุณ
3. การแยกระบบปฏิบัติการของคุณ MySql ของคุณติดตั้งจากส่วนที่เหลือ

ใช้สปินเดิลและคอนโทรลเลอร์แยกกันถ้าทำได้ 1

ตามด้วยแกนแยก

ตามด้วยพาร์ติชั่นแยกของชายยากจน

ฉันมีปัญหาที่คล้ายกันเมื่อเร็ว ๆ นี้เมื่อฉันใช้พื้นที่ดิสก์ทั้งหมดในเซิร์ฟเวอร์การจำลองแบบของฉัน ผลทันทีสำหรับการจำลองแบบการเกิดความผิดพลาดและจากนั้นฉันไม่สามารถเข้าสู่ MySQL เพราะไฟล์ mysqld.sock ไม่สามารถเปิดได้