كيفية منع حاوية قاعدة البيانات من النمو بعد تنظيف البيانات
قد تستمر حاوية قاعدة البيانات في النمو بعد تنظيف البيانات، لأن الصفوف المحذوفة وسجلات المعاملات والفهارس وسجلات الحاوية تخضع لقواعد مختلفة لاستعادة المساحة.
لا تفترض أن وحدة تخزين قاعدة البيانات تنمو لمجرد ارتفاع إجمالي البصمة التخزينية للحاوية. قِس بشكل منفصل دليل بيانات قاعدة البيانات، وأدلة WAL أو binlog، وملف سجل Docker، والطبقة القابلة للكتابة، ومسارات النسخ الاحتياطي أو الملفات المؤقتة. ثم حدّد ما إذا كانت مساحة قاعدة البيانات المحذوفة قابلة لإعادة الاستخدام داخليًا لكنها لم تُعَد إلى المضيف، أو ما إذا كانت إعادة الكتابة مطلوبة فعلًا، أو ما إذا كان ملف مختلف تمامًا لا يزال ينمو.
قِس المسار الذي لا يزال ينمو
سجّل حجم وحدة التخزين المسماة أو دليل قاعدة البيانات المرتبط، والطبقة القابلة للكتابة للحاوية، وسجل الحاوية على المضيف، ودليل سجل معاملات قاعدة البيانات، وأي دليل للتفريغ أو الملفات المؤقتة قبل دورة تنظيف واحدة وبعدها.
يبدأ دليل استكشاف أخطاء مساحة القرص في PostgreSQL بالمبدأ نفسه: اعثر على مكان استهلاك المساحة قبل اختيار عملية الاستعادة.
إذا كان سجل Docker وحده هو الذي ينمو، فلا علاقة لتنظيف قاعدة البيانات بالمشكلة. وإذا ظل ملف البيانات كبيرًا لكنه توقف عن الزيادة بعد التنظيف، فقد يكون المحرك يعيد استخدام الصفحات المحررة بالفعل، حتى إذا لم يرَ نظام ملفات المضيف أي انكماش.
ميّز بين مساحة قاعدة البيانات القابلة لإعادة الاستخدام ومساحة القرص المُعادة
لا تزيل العديد من قواعد البيانات المعتمدة على المعاملات كتل الملفات من منتصف الجدول فورًا بعد حذف الصفوف. بل تضع علامة على الصفحات الداخلية أو تستعيدها بحيث يمكن للإدخالات اللاحقة إعادة استخدام تلك المساحة، بينما يظل حجم الملف الأساسي كما هو.
تقدم PostgreSQL مثالًا واضحًا: إذ إن VACUUM يعيد استخدام المساحة داخليًا، لكنه عادةً لا يعيد مناطق الملف الوسطى إلى نظام التشغيل.
راقب ما إذا كان الملف يواصل النمو أثناء عمليات الإدراج الجديدة بعد التنظيف. فثبات حجم الملف مع انخفاض التضخم الداخلي يختلف عن النمو غير المنضبط، ولا يبرر عادةً إعادة كتابة طارئة.
استخدم طريقة الاستعادة الخاصة بمحرك قاعدة البيانات، لا تنظيف Docker العام
عندما يكون الهدف هو إعادة السعة إلى المضيف، حدّد المحرك وتنسيق التخزين أولًا. لا تستخدم PostgreSQL وMySQL أو MariaDB وSQLite أمر تقليص واحدًا قابلًا للتبادل، كما أن بعض عمليات الاستعادة تعيد كتابة ملفات كبيرة أو تقفل الجداول.
يوضح مقال عن تخزين MySQL كيف يمكن لـ OPTIMIZE إعادة بناء جداول InnoDB، بدل اعتبار تنفيذ DELETE دليلًا على أن المضيف يجب أن يستعيد البايتات فورًا.
انسخ قاعدة البيانات احتياطيًا وتأكد من توفر مساحة عمل حرة قبل أي عملية كثيفة إعادة الكتابة. فنظام ملفات خادم منزلي شبه ممتلئ هو أسوأ وقت لبدء أمر يحتاج إلى نسخة ثانية من جدول كبير.
تحقق من WAL وBinlog والاحتفاظ بالنسخ المتماثلة بشكل منفصل
يمكن أن تنمو سجلات المعاملات حتى بعد حذف صفوف التطبيق القديمة. فقد يؤدي فشل مهمة الأرشفة، أو فتحة نسخ متماثل قديمة، أو نسخة متماثلة متأخرة، أو معاملة طويلة، أو متطلب للاحتفاظ بنسخة احتياطية إلى إبقاء مقاطع السجل التاريخية على القرص.
توضح مذكرة حديثة عن استرداد PostgreSQL كيف يمكن لـ الاحتفاظ بـ WAL أن يستهلك مساحة التخزين بشكل مستقل عن بيانات الجدول التي نظفها المستخدم للتو.
لا تحذف ملفات WAL أو binlog يدويًا من نظام الملفات. أصلح سبب الاحتفاظ من خلال محرك قاعدة البيانات، ثم تحقق من استئناف إعادة التدوير الطبيعية.
حدّد سجلات Docker وتحقق من الطبقة القابلة للكتابة
قد تبدو حاوية قاعدة البيانات وكأنها تنمو لأن stdout أو stderr يُحفظ في سجل Docker غير محدود، أو لأن عملية تصدير مؤقتة أو ذاكرة تخزين مؤقت أو ملف قاعدة بيانات كُتب في طبقة الحاوية بدلًا من وحدة التخزين الدائمة المقصودة.
تشير حالة استخدام Docker المستضاف ذاتيًا إلى أن سجلات الحاويات قد تنمو بلا نهاية عند عدم إعداد تدوير السجلات.
اربط كل ملف كبير على المضيف بمساره داخل الحاوية قبل حذف أي شيء. اضبط تدوير السجلات لمنع النمو مستقبلًا، وانقل حالة قاعدة البيانات إلى وحدة تخزين صريحة بدلًا من الاعتماد على الطبقة القابلة للكتابة المؤقتة.
تحقق من أن التنظيف يوفر مساحة احتياطية مستدامة
بعد تنفيذ خطوة الاستعادة المختارة، شغّل حمل الكتابة المعتاد لفترة تمثيلية، وقارن بين المساحة الحرة على المضيف، وحجم ملف قاعدة البيانات، وحجم سجل المعاملات، وسجلات Docker، ومقاييس المساحة الحرة الداخلية أو التضخم.
يؤكد دليل تقليل مساحة تخزين PostgreSQL أن التقليص يتطلب صيانة مستهدفة، بدل افتراض أن كل عملية حذف يجب أن تقلل فورًا حجم ملف نظام التشغيل.
يكتمل الإصلاح عندما يُعاد استخدام نمو قاعدة البيانات المتوقع أو يُحدّ منه، وعندما لا يفقد المضيف سعة غير مفسرة بعد كل دورة تنظيف. ويوفر دليل ZimaSpace ذي الصلة حول النسخ الاحتياطي المتسق لحاوية قاعدة البيانات حدًا للرجوع قبل أي عملية تعيد كتابة ملفات قاعدة البيانات.
الأسئلة الشائعة
لماذا يؤدي حذف ملايين الصفوف أحيانًا إلى تحرير مساحة شبه معدومة على قرص المضيف؟
قد يضع المحرك علامة على تلك الصفحات لتصبح قابلة لإعادة الاستخدام داخل ملف قاعدة البيانات بدلًا من اقتطاع الملف نفسه. ويمكن أن يمنع ذلك النمو المستقبلي من دون تغيير حجم الملف الظاهر على المضيف.
هل ينبغي تشغيل إعادة كتابة كاملة كلما كبرت الحاوية؟
لا. فقد تتطلب العمليات التي تعيد الكتابة بكثافة أقفالًا ومساحة مؤقتة وعمليات إدخال وإخراج كبيرة. استخدمها فقط عندما تكون إعادة المساحة إلى المضيف ضرورية وبعد فهم المخاطر الخاصة بالمحرك.
هل يمكن لأمر Docker prune استعادة مساحة وحدة تخزين قاعدة البيانات؟
ليس بأمان عندما تكون وحدة التخزين لا تزال جزءًا من الحالة الدائمة لقاعدة البيانات. حدّد ما إذا كانت المساحة تخص السجلات أو الصور أو الحاويات المتوقفة أو بيانات قاعدة البيانات النشطة قبل تنفيذ عملية التنظيف.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكن لـ Plex مشاركة وحدة معالجة الرسومات (GPU) مع حاوية Docker أخرى؟
يمكن لـ Plex وحاوية أخرى غالبًا الوصول إلى وحدة معالجة الرسومات نفسها، لكن يجب اختبار دعم برنامج التشغيل، وتعيين الجهاز، وحِمل محرّك الفيديو، والذاكرة،...
كيفية معرفة ما إذا كان خطأ Plex ناتجًا عن العميل أم الخادم
أعِد إنتاج العنصر نفسه على عميل آخر، وقارن مسار الجلسة، ثم اجمع أدلة من الخادم فقط بعد أن يحدد النطاق موضع الفشل الفعلي.
كيفية إعداد ذاكرة التخزين المؤقت وموقع التخزين المؤقت لتحويل الترميز في Plex
احمِ حالة Plex الدائمة مع وضع الملفات المؤقتة للتحويل على مساحة تخزين محلية مناسبة، ثم تحقّق من التنظيف والمساحة الحرة وسلوك إعادة التشغيل.
