การลดขนาดไฟล์ฐานข้อมูล MongoDB

ฉันมีฐานข้อมูล MongoDB ที่ครั้งหนึ่งเคยมีขนาดใหญ่ (> 3GB) ตั้งแต่นั้นมาเอกสารก็ถูกลบไปและฉันคาดหวังว่าขนาดของไฟล์ฐานข้อมูลจะลดลงตามไปด้วย

แต่เนื่องจาก MongoDB ยังคงมีพื้นที่จัดสรรไฟล์จึงยังคงมีขนาดใหญ่

ฉันอ่านที่นี่และมีคำสั่ง admin ที่mongod --repairใช้เพื่อเพิ่มพื้นที่ว่างที่ไม่ได้ใช้ แต่ฉันมีพื้นที่ว่างบนดิสก์ไม่เพียงพอที่จะเรียกใช้คำสั่งนี้

คุณรู้วิธีที่ฉันสามารถปลดปล่อยพื้นที่ว่างที่ไม่ได้ใช้?

UPDATE:ด้วยcompactคำสั่งและ WiredTiger ดูเหมือนว่าพื้นที่ดิสก์เพิ่มเติมจะถูกปล่อยสู่ระบบปฏิบัติการจริง

UPDATE:ตั้งแต่ v1.9 + มีcompactคำสั่ง

คำสั่งนี้จะทำการบีบอัด "ในบรรทัด" มันจะยังคงต้องการพื้นที่เพิ่มเติม แต่ไม่มาก

MongoDB บีบอัดไฟล์โดย:

• คัดลอกไฟล์ไปยังตำแหน่งใหม่
• การวนลูปผ่านเอกสารและสั่งซื้อ / แก้ไขซ้ำอีกครั้ง
• แทนที่ไฟล์ต้นฉบับด้วยไฟล์ใหม่

คุณสามารถทำเช่นนี้ "อัด" โดยการทำงานหรือการเชื่อมต่อโดยตรงและทำงานmongod --repairdb.repairDatabase()

ไม่ว่าในกรณีใดคุณต้องการพื้นที่ในการคัดลอกไฟล์ ตอนนี้ฉันไม่รู้ว่าทำไมคุณไม่มีที่ว่างพอที่จะทำการบีบอัดอย่างไรก็ตามคุณมีตัวเลือกบางอย่างถ้าคุณมีคอมพิวเตอร์เครื่องอื่นที่มีพื้นที่มากกว่า

1. ส่งออกฐานข้อมูลไปยังคอมพิวเตอร์เครื่องอื่นโดยติดตั้ง Mongo (โดยใช้mongoexport) จากนั้นคุณสามารถนำเข้าฐานข้อมูลเดียวกันนั้น (โดยใช้mongoimport) ซึ่งจะส่งผลให้ฐานข้อมูลใหม่ที่ถูกบีบอัดเพิ่มเติม ตอนนี้คุณสามารถหยุดการmongodแทนที่ต้นฉบับด้วยไฟล์ฐานข้อมูลใหม่และคุณพร้อมที่จะไป
2. หยุด Mongo ปัจจุบันและคัดลอกไฟล์ฐานข้อมูลไปยังคอมพิวเตอร์ที่ใหญ่กว่าและเรียกใช้การซ่อมแซมในคอมพิวเตอร์เครื่องนั้น จากนั้นคุณสามารถย้ายไฟล์ฐานข้อมูลใหม่กลับไปที่คอมพิวเตอร์เดิม

ขณะนี้ยังไม่มีวิธีที่ดีในการ "กะทัดรัดในสถานที่" โดยใช้ Mongo และ Mongo สามารถดูดพื้นที่ได้อย่างแน่นอน

กลยุทธ์ที่ดีที่สุดในขณะนี้สำหรับการบดอัดคือการเรียกใช้การตั้งค่า Master-Slave จากนั้นคุณสามารถกระชับ Slave ปล่อยให้มันจับและสลับไปมา ฉันรู้ว่ายังมีขนเล็กน้อย บางทีทีม Mongo อาจจะมาพร้อมกับการบดอัดที่ดีขึ้น แต่ฉันไม่คิดว่ามันจะอยู่ในอันดับต้น ๆ ของพวกเขา ปัจจุบันพื้นที่ไดรฟ์มีราคาถูก (และมักจะเป็น)

ฉันมีปัญหาเดียวกันและแก้ไขได้โดยทำสิ่งนี้ที่บรรทัดคำสั่ง:

mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename

ดูเหมือนว่า Mongo v1.9 + จะรองรับคอมแพคในสถานที่!

> db.runCommand( { compact : 'mycollectionname' } )

ดูเอกสารได้ที่นี่: http://docs.mongodb.org/manual/reference/command/compact/

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

กระชับการรวบรวมทั้งหมดในฐานข้อมูลปัจจุบัน

db.getCollectionNames().forEach(function (collectionName) {
    print('Compacting: ' + collectionName);
    db.runCommand({ compact: collectionName });
});

หากคุณต้องการเรียกใช้การซ่อมแซมแบบเต็มให้ใช้repairpathตัวเลือก ชี้ไปที่ดิสก์ที่มีพื้นที่ว่างมากขึ้น

ตัวอย่างเช่นบน Mac ของฉันฉันได้ใช้:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair

อัปเดต: ต่อตั๋ว MongoDB Core Server 4266คุณอาจต้องเพิ่ม--nojournalเพื่อหลีกเลี่ยงข้อผิดพลาด:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair --nojournal

เริ่มต้นด้วยMongo รุ่น 2.8 คุณสามารถใช้การบีบอัดได้ คุณจะมีการบีบอัด 3 ระดับด้วยเอ็นจิ้น WiredTiger, mmap (ซึ่งเป็นค่าเริ่มต้นใน 2.6 ไม่มีการบีบอัด):

• ไม่มี
• เร็ว (โดยค่าเริ่มต้น)
• zlib

นี่คือตัวอย่างของพื้นที่ที่คุณสามารถบันทึกข้อมูลได้ 16 GB:

ข้อมูลที่จะนำมาจากนี้บทความ

เราต้องการวิธีแก้ปัญหา 2 วิธีโดยใช้ StorageEngine

1. เครื่องยนต์ MMAP ():

คำสั่ง: db.repairDatabase ()

หมายเหตุ: repairDatabase ต้องใช้พื้นที่ว่างในดิสก์เท่ากับขนาดของชุดข้อมูลปัจจุบันของคุณบวก 2 กิกะไบต์ หากวอลุ่มที่เก็บ dbpath ไม่มีพื้นที่เพียงพอคุณสามารถต่อวอลุ่มแยกต่างหากและใช้สำหรับการซ่อมแซม เมื่อติดตั้งไดรฟ์ข้อมูลแยกต่างหากสำหรับ repairDatabase คุณต้องเรียกใช้ repairDatabase จากบรรทัดคำสั่งและใช้สวิตช์ --repairpath เพื่อระบุโฟลเดอร์ที่ใช้เก็บไฟล์ซ่อมแซมชั่วคราว เช่น: ลองนึกภาพขนาดฐานข้อมูลเท่ากับ 120 GB หมายถึง (120 * 2) +2 = 242 GB พื้นที่ว่างในฮาร์ดดิสก์

อีกวิธีหนึ่งในการรวบรวมข้อมูลอย่างชาญฉลาดคำสั่ง: db.runCommand ({compact: 'collectionName'})

2. WiredTiger: แก้ไขอัตโนมัติด้วยตนเอง

มีความสับสนอย่างมากเกี่ยวกับการเรียกคืนพื้นที่ใน MongoDB และการปฏิบัติที่แนะนำบางอย่างเป็นอันตรายอย่างยิ่งที่จะทำในการปรับใช้บางประเภท รายละเอียดเพิ่มเติมด้านล่าง:

TL; DR repairDatabaseพยายามกู้ข้อมูลจากการปรับใช้ MongoDB แบบสแตนด์อโลนที่พยายามกู้คืนจากความเสียหายของดิสก์ ถ้ามันกู้คืนพื้นที่มันเป็นอย่างหมดจดผลข้างเคียง repairDatabaseการกู้คืนพื้นที่ไม่ควรพิจารณาหลักของการทำงาน

กู้คืนพื้นที่ในโหนดสแตนด์อะโลน

WiredTiger:สำหรับโหนดแบบสแตนด์อโลนที่มี WiredTiger การรันcompactจะปล่อยพื้นที่ไปยัง OS ด้วยหนึ่ง caveat: compactคำสั่งบน WiredTiger บน MongoDB 3.0.x ได้รับผลกระทบจากข้อผิดพลาดนี้: SERVER-21833ซึ่งได้รับการแก้ไขใน MongoDB 3.2.3 ก่อนหน้าเวอร์ชันนี้compactบน WiredTiger อาจล้มเหลวอย่างเงียบ ๆ

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

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

สำหรับวิธีการผจญภัยที่น้อยกว่าการรันmongodumpและmongorestoreอาจทำได้เช่นกันในการปรับใช้ MMAPv1 ขึ้นอยู่กับขนาดของการปรับใช้ของคุณ

กู้คืนพื้นที่ในชุดแบบจำลอง

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

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

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

เกี่ยวกับ repairDatabase

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

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

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

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

ผลที่ตามมาของrepairDatabaseชุดแบบจำลอง

ในชุดเรพลิกา MongoDB คาดว่าโหนดทั้งหมดในชุดจะมีข้อมูลที่เหมือนกัน หากคุณรันrepairDatabaseบนโหนดชุดเรพลิกามีโอกาสที่โหนดจะมีความเสียหายที่ตรวจไม่พบและrepairDatabaseจะลบเอกสารที่เสียหายให้คุณตามหน้าที่

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

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

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

พฤติกรรมของกระบวนการบดอัดขึ้นอยู่กับเอ็นจิ้น MongoDB ดังต่อไปนี้

db.runCommand({compact: collection-name })

MMAPv1

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

ต้องการพื้นที่ดิสก์เพิ่มเติมไม่เกิน 2GB ในระหว่างการดำเนินการบดอัด

ล็อคระดับฐานข้อมูลจะถูกเก็บไว้ในระหว่างการดำเนินการบดอัด

WiredTiger

เอ็นจิ้น WiredTiger ให้การบีบอัดตามค่าเริ่มต้นซึ่งใช้พื้นที่ดิสก์น้อยกว่า MMAPv1

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

สำหรับเอ็นจิ้น MMAPv1กะทัดรัด doest จะไม่ส่งคืนพื้นที่ไปยังระบบปฏิบัติการ คุณต้องดำเนินการซ่อมแซมเพื่อปล่อยพื้นที่ที่ไม่ได้ใช้

db.runCommand({repairDatabase: 1})

Mongodb 3.0 ขึ้นไปมีเอ็นจิ้นการจัดเก็บใหม่ - WiredTiger ในกรณีของฉันการสลับเอ็นจิ้นลดการใช้ดิสก์จาก 100 Gb เป็น 25Gb

ไฟล์ฐานข้อมูลไม่สามารถลดขนาดได้ ในขณะที่ฐานข้อมูล "ซ่อม" มันเป็นไปได้เฉพาะสำหรับเซิร์ฟเวอร์ mongo ที่จะลบไฟล์บางส่วน หากข้อมูลจำนวนมากถูกลบเซิร์ฟเวอร์ mongo จะ "ปล่อย" (ลบ) ในระหว่างการซ่อมแซมไฟล์บางไฟล์ที่มีอยู่

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

เมื่อฉันมีปัญหาเดียวกันฉันหยุดเซิร์ฟเวอร์ mongo ของฉันและเริ่มต้นอีกครั้งด้วยคำสั่ง

mongod --repair

ก่อนดำเนินการซ่อมแซมคุณควรตรวจสอบว่าคุณมีพื้นที่ว่างเพียงพอบน HDD ของคุณหรือไม่ (ขั้นต่ำ - คือขนาดของฐานข้อมูลของคุณ)

สำหรับโหมดสแตนด์อโลนคุณสามารถใช้คอมแพคหรือซ่อมได้

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

ข้อสรุปของฉันคือวิธีที่ดีที่สุดในการลดขนาดของชุดชาร์ด / เรพลิกาคือการทำสมาชิก resync สลับที่สองหลักและซิงค์อีกครั้ง

mongoDB -repair ไม่แนะนำในกรณีของคลัสเตอร์ที่แตกออก

หากใช้คลัสเตอร์เรพลิกาชุดเรพลิกาให้ใช้คำสั่งขนาดกะทัดรัดมันจะเขียนใหม่และจัดเรียงข้อมูลและไฟล์ดัชนีทั้งหมดของคอลเลกชันทั้งหมด ไวยากรณ์:

db.runCommand( { compact : "collection_name" } )

เมื่อใช้กับ force: true, compact จะรันบนชุดหลักของชุดเรพลิกา เช่น db.runCommand ( { command : "collection_name", force : true } )

ประเด็นอื่น ๆ ที่ควรพิจารณา: - บล็อกการดำเนินการ แนะนำให้รันในหน้าต่างการบำรุงรักษา - หากแบบจำลองตั้งค่าการทำงานบนเซิร์ฟเวอร์ที่แตกต่างกันจะต้องดำเนินการกับสมาชิกแต่ละคนแยกกัน - ในกรณีที่มีการแบ่งส่วนออกเป็นกลุ่มขนาดกะทัดรัดจำเป็นต้องดำเนินการกับสมาชิกแต่ละส่วนที่แยกออกจากกัน ไม่สามารถดำเนินการกับอินสแตนซ์ mongos ได้

เพียงวิธีเดียวที่ฉันสามารถทำได้ ไม่มีการรับประกันความปลอดภัยของข้อมูลที่คุณมีอยู่ ลองด้วยความเสี่ยงของคุณเอง

ลบไฟล์ข้อมูลโดยตรงและรีสตาร์ท mongod

ตัวอย่างเช่นด้วย ubuntu (พา ธ เริ่มต้นไปที่ data: / var / lib / mongodb) ฉันมีไฟล์คู่ที่มีชื่อ like: collection ฉันเก็บ collection.0 และลบคนอื่น ๆ ทั้งหมด

ดูเหมือนจะเป็นวิธีที่ง่ายขึ้นถ้าคุณไม่มีข้อมูลร้ายแรงในฐานข้อมูล