إزالة البيانات من قاعدة بيانات قابلة للمشاركة

مقال حول كيفية حل مشكلة تحسين عملية حذف الملفات من نظام مجزأ. يتعلق الأمر بمشروع لمشاركة الملفات والعمل معها. كان النظام شركة ناشئة قبل حوالي 8 سنوات ، ثم أطلق النار بنجاح وتم بيعه عدة مرات. يحتوي المشروع على 4 مطورين مع المشروع منذ البداية ، وهو أمر قيم للغاية. تقليديًا ، لم يكن لديك وقت للكتابة ، أو أنها ليست ذات صلة كبيرة.

لماذا تقرأ هذا ولماذا أكتب كل هذا؟ أود أن أتحدث عن أشعل النار التي تقع بعناية داخل النظام وتنبض حتى تنبثق النجوم من العين.

أريد أن أقول شكراً جزيلاً لـ Hanna_Hlushakova على العمل معًا ، لإنهاء المشروع والمساعدة في إعداد المقالة. بشكل أساسي ، ستجد أوصافًا للمشكلة وخوارزمية حلها ، والتي استخدمناها ، ولا توجد أمثلة على التعليمات البرمجية أو هياكل البيانات أو غيرها من الأشياء الضرورية. لا أعرف ما إذا كانت تجربتي ستساعدك على تجنب أشعل النار في المنزل ، ولكن آمل أن تحصل على شيء مفيد. ربما ستكون هذه المقالة خسارة لا رجعة فيها للوقت الثمين.

عن المشروع

المشروع هو واحد من الشركات الرائدة في ساحة جارتنر ، ولديه شركات عملاء لديها أكثر من 300 ألف موظف في الولايات المتحدة وأوروبا ، وعدة مليارات من الملفات للصيانة.

يتم استخدام التقنيات التالية في المشروع: خوادم Microsoft و C # .net وقاعدة بيانات MS SQL و 14 خادمًا نشطًا + 14 في وضع النسخ المتطابق للبيانات.

حجم قواعد البيانات يصل إلى 4 تيرابايت ، الحمل المستمر في ساعات العمل حوالي 400 ألف طلب في الدقيقة.

هناك الكثير من منطق الأعمال في قاعدة البيانات:
450 طاولة
1000 إجراء مخزن
80000 سطر من كود SQL
تقليديا ، إما لم يكن لديهم الوقت لكتابة الوثائق ، أو أنها ليست ذات صلة.

حول المهمة

تتمثل المهمة في إعادة حذف الملفات من التخزين التي تم حذفها بالفعل من قبل العملاء ، وانتهت فترة تخزين الملفات المحذوفة ، في حالة رغبتها في استعادتها. في الإصدار الحالي ، وفقًا لحسابات الشركة نفسها ، تم تخزين الملفات التي تم حذفها قبل عام واحد على الخوادم ، على الرغم من أنه وفقًا لشروط العمل ، كان يجب تخزينها لمدة شهر واحد فقط. نظرًا لأن بعض الملفات يتم تخزينها على S3 ، دفعت الشركة مقابل البيانات الإضافية ، وكان العملاء الذين استخدموا التخزين المحلي يتساءلون عن سبب شغل الملفات مساحة أكبر مما ينبغي.

قواعد بيانات shardovany لعميل الشركة.

كيف عملت الإزالة في وقت سابق؟

على خادم عالمي بمعلومات عن جميع الملفات في النظام ، تم تشكيل نطاقات من 15 ألف معرف ملف.

بعد ذلك ، وفقًا للجدول الزمني ، تم بدء مسح الخادم لمجموعة من معرفات الملفات.
تم نقل حدود النطاق إلى كل قطعة.

أرسل Shard ردًا على الملفات التي تم العثور عليها من النطاق.

أضاف الخادم الرئيسي الملفات المفقودة إلى قائمة الانتظار لحذفها في قاعدة البيانات الخاصة به.
بعد ذلك ، من جدول قائمة الانتظار ، تلقت خدمة حذف الملفات الفعلية من التخزين مجموعة من المعرّفات للحذف ، وبعد ذلك أرسلت تأكيدًا بأنها ستحذف الملفات وبدأ التحقق من جميع الأجزاء ما إذا كانت هذه الملفات مستخدمة هناك.
مع زيادة عدد الملفات ، بدأ هذا النهج يعمل ببطء شديد ، حيث كان هناك عدة مليارات من الملفات ، وزاد عدد النطاقات بشكل ملحوظ. لا تزال الملفات المحذوفة أقل من 5٪ مقارنة بالعدد الإجمالي ، على التوالي ، من غير الفعال للغاية فرز مليارات الملفات للعثور على عدة ملايين من الملفات المحذوفة.

على سبيل المثال ، عادةً بعد حذف المستخدم للملف ، يجب تخزينه لمدة شهر واحد ، في حالة الحاجة إلى استعادته. بعد هذه الفترة ، يجب حذف الملف من قبل البرنامج من المستودع. مع العدد الحالي للملفات ، وعدد النطاقات وسرعة تجاوز النطاقات ، قد يستغرق الخادم سنة واحدة لتجاوز جميع النطاقات تمامًا.
من الواضح أن المكان لم يتم تحريره ، وقد تسبب ذلك في استياء المستخدمين ، حيث قامت خوادمهم بتخزين ملفات أكثر بكثير مما كان يجب الإبلاغ عنه. دفعت شركة الخدمة نفسها مقابل مكان إضافي على S3 ، والذي كان خسارة مباشرة لها.

فقط على S3 في الوقت الذي بدأ فيه العمل ، تم تخزين 2 بيتابايت من الملفات المحذوفة ، وهذا فقط على السحابة. بالإضافة إلى ذلك ، كان هناك عملاء تم تخزين ملفاتهم على خوادمهم المخصصة ، والتي واجهت نفس المشكلة: مساحة الخادم مشغولة بالملفات التي حذفها المستخدمون ولكن لم يتم حذفها من الخادم.

ماذا قررت ان تفعل؟

قررنا تتبع أحداث الإزالة:

• حذف العميل الملف ثم انتهت صلاحيته.
• قام المستخدم بحذف الملف على الفور دون إمكانية الاسترداد.

عند حذف ملف من قاعدة بيانات مجزأة ، قررنا استخدام نهج متفائل وإزالة أحد الاختبارات للاستخدام. علمنا أن 99٪ من الملفات تُستخدم في جزء واحد فقط. قررنا إضافة الملف على الفور إلى قائمة انتظار الحذف ، ولا نتحقق من الأجزاء المتبقية لاستخدام هذا الملف ، حيث سيتم إجراء الفحص مرة أخرى عندما يؤكد الحذف من المتجر الخدمة.

بالإضافة إلى ذلك ، تركوا الوظيفة الحالية التي فحصت الملفات المحذوفة حسب النطاقات من أجل إضافة الملفات التي تم حذفها قبل إصدار الإصدار الجديد.

يتم تجميع كل ما تم حذفه على الجزء في جدول ثم نقله إلى خادم واحد ، مع معلومات حول جميع الملفات.

على هذا الخادم ، يتم إرساله إلى جدول قائمة انتظار الحذف.

في جدول الحذف قبل الحذف ، يتم التحقق من عدم استخدام الملف في جميع الأجزاء. كان هذا الجزء من الشيك هنا قبل تغيير الرمز ، وقرروا عدم لمسه.

ما الذي احتجت إلى تغييره في الكود؟

في كل جزء من الأجزاء ، تمت إضافة جدول يجب كتابة معرف الملف المحذوف إليه.

وجدنا جميع الإجراءات لحذف الملفات من قاعدة البيانات ، لم يكن هناك سوى 2. بعد أن حذف المستخدم الملف ، لا يزال الملف موجودًا في قاعدة البيانات لبعض الوقت.

في إجراء حذف ملف من قاعدة البيانات ، قمنا بإضافة إدخال إلى هذا الجدول المحلي مع الملفات المحذوفة.

على الخادم العام بالملفات ، قاموا بعمل JOB يقوم بتنزيل قائمة الملفات من قواعد بيانات Shard. مجرد استدعاء إجراء من قاعدة بيانات قابلة للمشاركة ، يقوم بحذف في الداخل ويعرض قائمة بالملفات في OUTPUT. في MS SQL Server ، يعد السحب من خادم بعيد أسرع بكثير من الإدخال إلى خادم بعيد. كل هذا يتم في كتل.
ثم تتم إضافة هذه الملفات إلى جدول قائمة انتظار الحذف على الخادم العام.
تمت إضافة جدول بمعرف جزء إلى جدول قائمة الانتظار لمعرفة مصدر حدث الحذف.

كيف اختبرها الجميع؟

هناك 3 بيئات:

ديف هي بيئة تطوير. الكود مأخوذ من فرع تطوير الجيث. من الممكن نشر إصدار مختلف من التعليمات البرمجية على IIS وإنشاء عدة إصدارات من التنسيق. سيتم الاتصال ببيئة التطوير من العميل داخل VPN. حتى وقت قريب ، كان الإزعاج فقط مع قواعد البيانات ، حيث أن جميع التغييرات على قاعدة البيانات يمكن أن تكسر عمل أجزاء أخرى من النظام. ثم أصبحت القواعد محلية. يمكن بالفعل صب كود تشغيل على خوادم ديف مع قواعد البيانات حتى لا تدمر عمل الجميع. في بيئة التطوير ، هناك 3 أجزاء ، بدلاً من 12 ، موجودة في المنتج ، ولكن هذا عادة ما يكون كافيًا لاختبار التفاعل.

التقسيم - البيئة هي نفسها مع المنتج وفقًا لإصدار الكود (تقريبًا نفس الشيء ، كما هو نادر ، ولكن هناك تغييرات مباشرة على المنتج من قبل المسؤولين). نسخة من الكود من الفرع الرئيسي. في بعض الأحيان تم اكتشاف بعض الاختلافات مع الرمز على المنتج في قاعدة البيانات ، ولكنها بشكل عام متطابقة. هناك أيضا 3 شظايا في التدريج وكذلك في البكر. لا يوجد حمل على التدريج وكذلك على ديف. هنا يمكنك إجراء اختبارات التكامل بالفعل تمامًا ، لأن الرمز يطابق المنتج. يجب أن تجتاز جميع الاختبارات ، وهذا شرط مسبق قبل الانتقال إلى النشر.

معمل بيرف حيث يتم إجراء الاختبارات تحت الحمل. يتم إنشاء الحمل باستخدام جيميتر ، أقل بعشر مرات من المنتج ، وهناك قطعة واحدة فقط ، مما يؤدي في بعض الأحيان إلى إزعاج. يتم أخذ بيانات المبيعات ، ثم إخفاء هويتها واستخدامها في مختبر الأداء. جميع الخوادم من نفس التكوين كما هو الحال في همز.

الحمل أقل بعشر مرات ، لأنه يُفترض أن هذا حمل تقريبي يأتي إلى همز لقطعة واحدة. الجانب السلبي هو أن القاعدة العالمية غير مستغلة بشكل كبير ، على عكس المبيعات. وإذا كانت التغييرات تتعلق بشكل أساسي بقاعدة البيانات العالمية بالملفات ، فيمكنك الاعتماد على نتائج الاختبار فقط تقريبًا - على المنتج قد لا يعمل ذلك. على الرغم من أن معمل الأداء لا يتطابق بشكل مثالي مع الحمل مع المنتج ، فإن القدرة على الاختبار تحت الحمل تساعد بالفعل في التقاط العديد من الأخطاء قبل النشر في المنتج.

هناك أيضًا خادم نسخ احتياطي حيث يمكنك رؤية البيانات من البيع من أجل التقاط بعض الحالات. بشكل عام ، تعمل الشركة بموجب ترخيص يحظر على المطورين منح الوصول إلى بيانات المبيعات ، ووصول فريق الإدارة والدعم (العمليات) إلى التطوير ، لذلك تحتاج إلى طلب المساعدة من مسؤولي قواعد البيانات. تجعل بيانات المبيعات الاختبار أمرًا سهلاً للغاية ، لأن بعض الحالات تنشأ فقط على بيانات إنتاجية ومن المفيد جدًا دراسة البيانات في نظام حقيقي من أجل فهم كيفية عمل النظام للمستخدم.

أثناء الاختبارات على مختبر الأداء ، اتضح أن حمل حذف الملفات من التخزين لم يتم إدراكه من الكلمة على الإطلاق. عند تنفيذ اختبار الحمل ، اخترنا الطلبات الأكثر شيوعًا من برنامج العميل ، والتي لم يتم تضمين بعضها في تنظيف وحدة التخزين. نظرًا لأن هذه قاعدة بيانات ، فقد اتضح إجراء اختبار مبسط لجميع الكائنات التي تم تغييرها مع استدعاء الإجراءات التي تم تغييرها على بيانات مختلفة يدويًا. (على الخيارات التي عرفت عنها).
بالإضافة إلى ذلك ، في اختبارات التكامل والكمال ، تم التركيز بشكل رئيسي على النوع الأكثر شيوعًا لتخزين الملفات.

ميزة إضافية لمختبر الأداء ، والتي لم يتم اكتشافها على الفور ، هي عدم تطابق كمية البيانات في بعض الجداول على المنتج والكمال. بمعنى أن جميع وظائف المبيعات تعمل على الكمال ، والتي تولد البيانات ، ولكن لا يوجد دائمًا شيء يعالج البيانات التي تم إنشاؤها في الجدول. وعلى سبيل المثال ، قائمة انتظار الجدول المذكورة أعلاه للحذف على العطر أكبر بكثير من العارضة - 20 مليون سجل على العطر و 200 ألف سجل على الإصدار المحترف

عملية النشر

عملية النشر قياسية جدًا. لم تكن هناك تغييرات في رمز التطبيق لهذه المهمة ، كل التغييرات موجودة فقط في قاعدة البيانات. يتم إدخال DBA دائمًا في قاعدة البيانات ؛ هذه العملية ليست مؤتمتة. يتم إعداد نسختين من البرامج النصية - لتطبيق التغييرات وللف التغييرات السابقة ، ويتم كتابة تعليمات لـ DBA. يتم دائمًا إنشاء نسختين من النصوص البرمجية ، ويتم اختبارهما بالضرورة بحثًا عن التراجع والتراجع عن التغييرات. وتستخدم هذه البرامج النصية نفسها لتطبيق التغييرات على التدرج ومختبر الأداء قبل إطلاق التكامل واختبار الحمل.

ماذا حدث بعد الانتشار؟

في أول 5 ساعات بعد النشر ، وصل مليون حدث إلى أن برنامج العميل تلقى خطأ أثناء محاولة تنزيل الملف. حدث "تلف الملف". هذا يعني أن العميل يحاول تنزيل الملف ، ولكن لم يتم العثور على الملف في المستودع. عادة ما تكون هذه الأحداث إما ليست على الإطلاق ، أو تقاس من 1 إلى 2 ألف في اليوم.

يجب أن أقول على الفور أن الأمر استغرق أسبوعًا واحدًا على الأقل للعثور على سبب الفشل في فريق مكون من 3 أشخاص وأحيانًا 5 أشخاص (بما فيهم أنا).

جمعنا القائمة الكاملة للملفات التي أتى حدث "File Corrupted" لها.

على الرغم من حقيقة أن هناك أكثر من مليون حدث وكانوا جميعهم من مستخدمين مختلفين وشركات مختلفة ، لم يكن هناك سوى 250 ملفًا فريدًا في هذه القائمة.

تم رفع DBA على خادم النسخ الاحتياطي للتحقيق في النسخ الاحتياطية لقاعدة البيانات في وقت وصول الأحداث. هناك عدد غير قليل من الجداول في قواعد المشروع مع جميع أنواع السجلات التي ساعدت في التحليل. حتى عند حذف المعلومات من قاعدة البيانات ، تتم إضافة سجل إلى ما تم حذفه وبأي حدث. في همز ، يتم تخزين هذه السجلات لمدة 1 أسبوع ، ثم يتم دمجها في خادم الأرشيف.

وكذلك الجداول ذات السجلات التي ساعدت كثيرًا في تحليل ما حدث:
يتم الاحتفاظ بسجل كامل مع أحداث العميل على كل جزء

على الخادم العالمي:

• سجل الطلبات لتنزيل جميع الملفات من قبل المستخدمين
• سجل تحميل الملفات إلى النظام من المستخدمين
• سجل أحداث FileCorrupt
• ملف السجل لإلغاء الحذف من التخزين
• سجل الملفات المحذوفة من قاعدة البيانات

بالإضافة إلى ذلك ، كان يتوفر ELK مع سجلات التطبيق.

تمكنا من تكرار الخطأ في بيئة التطوير ، مما أكد صحة الافتراض. في البداية ، لم يأخذ أحد هذه الفرضية على محمل الجد ، حيث كان من الصعب جدًا تصديق أن العديد من العوامل تزامنت في نفس الوقت وجاء العديد من المستخدمين في هذا الوقت بالذات.

ما الخطأ الذي حدث؟

اتضح أن النظام كان يحتوي على حوالي 250 (للمقارنة ، مليارات الملفات في النظام) ملفات شائعة للغاية. 250 نعم!

كانت هذه الملفات لا تزال قديمة جدا. في الوقت الذي تم فيه تحميل هذه الملفات إلى النظام ، تم استخدام نظام آخر لتوليد مفتاح الملف للتخزين.

اتضح أنه بالنسبة لهذا النوع من المفاتيح ، فإن طريقة الإزالة المادية من التخزين الفعلي تتصرف بشكل مختلف عن الملفات الأخرى.

في الفصل مع الحذف ، يوجد مقطع تعليمات برمجية مع حالة خاصة للملفات ذات المفتاح القديم. يقوم النظام ، في وقت الحذف ، قبل التحقق من عدم وجود الملف على أجزاء ، بنقل هذا الملف القديم إلى موقع آخر. حسنا ، هذا لم ينجح.

وتبين أنه في الوقت الحالي تم نقل الملف (وسأذكر أنه شائع جدًا) ، إذا كان أحد المستخدمين يحاول منحه حقوق مستخدم جديدة ، فإن برنامج العميل ينتقل إلى التخزين لهذا الملف ، ولكن الملف ليس في المكان الصحيح. لأنه يتم نقله ، بحيث لا يعمل. ويرسل برنامج العميل رسالة مفادها أن الملف معطل. في قاعدة البيانات ، تم وضع علامة عليها على أنها مكسورة. ويتم حذف جميع المعلومات من قاعدة البيانات (حسنًا ، كلها تقريبًا).

في هذه الأثناء ، يكتشف روتين الفحص الجزئي أن الملف قيد الاستخدام. ويرسل الرد الذي تحتاجه لإعادته. ولكن تم بالفعل حذف جميع المعلومات من قاعدة البيانات ، ومن المستحيل إعادتها.

مضحك هاه؟

أي ، عندما تم حذف الملف ، كان المستخدم في تلك الفترة الزمنية عندما تم نقل الملف ، وفحص الأجزاء ، وفي هذه المرحلة أرسل المستخدم طلبًا للتنزيل.

ها هي - حمولة عالية في العمل ، عندما تتطابق أكثر المطابقات روعة.



بعد التعافي من المفاجأة والتراجع عن كل شيء ، تأكدنا من أن الملفات من المستخدمين على قيد الحياة ، حيث تم استعادتها من أقراص عملاء آخرين.

بطبيعة الحال ، كان كل شيء على ما يرام في الاختبارات ، لأنه أثناء الاختبار تم حذف الملفات الأحدث بنوع مفتاح جديد تم استخدامه في السنوات الخمس الماضية. لا يتم نقل هذه الملفات إلى موقع تخزين آخر في وقت الحذف.

تضاءل تفاؤلنا ، وقررنا عدم السير في المسار الأكثر تفاؤلاً.

بأثر رجعي

قررنا أننا بحاجة إلى إضافة اختبارات لأنواع مختلفة من المخازن
أضف حملًا إلى مختبر الأداء يستخدم المكالمات عند إزالته من التخزين
إغلاق شروط السباق الشهيرة
أضف المراقبة (على الرغم من أنها ستكون في الخطط ، لكنها لا تتناسب مع النطاق الأصلي)

حول المراقبة

قرروا القيام بالمراقبة على الفور ، ولكن بعد ذلك تلاشى في الخلفية ، حيث كان من الضروري الانتشار بشكل أسرع.

للمراقبة ، استخدم المشروع Zabbix و ELK و Grafana و NewRelic و SQL Sentry ونسخة تجريبية من AppDynamics.

من هذا ، في مختبر pef كان NewRelic و SQL Sentry.

لقد قمنا بالفعل بقياس جميع مقاييس النظام ، لذلك أردنا قياس مقاييس الأعمال. كانت لدي خبرة في تنظيم مثل هذه المراقبة من خلال Zabbix - قررنا أن نفعل نفس الشيء.

المخطط بسيط للغاية في قاعدة البيانات لإنشاء جدول يتم من خلاله جمع المقاييس اللازمة بواسطة JOB وإجراء من شأنه تحميل المقاييس التي تم جمعها إلى Zabbix.

المقاييس:

• عدد الملفات الموجودة في قائمة الانتظار للحذف على أساس عالمي
• عدد الملفات المدرجة في قائمة الانتظار بواسطة الخادم
• عدد الملفات المرسلة إلى برنامج إلغاء التثبيت من المستودع
• عدد الملفات المحذوفة
• عدد الأحداث FileCorrupt
• عدد الملفات المراد حذفها على كل جزء

تم تنفيذ المراقبة ونشرها في المنتج بشكل منفصل ، قبل أن يبدأوا في نشر تطبيق جديد للحذف.

حل جديد

بشكل عام ، قررنا أنه من الأفضل الإفراط في تناول الطعام بدلاً من عدم النوم ، ووضعنا خطة جديدة.

1. تحقق من نفس الجزء الذي لم يعد فيه أحد يستخدم الملف بالتأكيد ، وقم بنقل الملفات غير المستخدمة فقط إلى الخادم ؛
2. عند النقل إلى الخادم ، اجمع كل الملفات في الجدول وتحقق من عدم استخدام الملفات في الأجزاء قبل وضعها في جدول قائمة انتظار dequeue ؛
3. عند استخدام ملف والبحث عنه في النظام ، ضع علامة على قائمة انتظار dequeue في الجدول كملف يتطلب التحقق ؛
4. إرجاع الملفات التي لم يتم البحث عنها فقط ؛
5. الملفات التي تم البحث عنها ، وإعادة التحقق من وجود أجزاء ؛
6. بشكل عام ، قم بإزالة التحقق من الإجراء الذي يحذف الملف ، حيث يجب أن يعمل بسرعة - ويجب ألا يصل الملف المستخدم إليه من حيث المبدأ ؛
7. ضع في الاعتبار في الإجراء أن كل شيء يحذف من الملف المطروق الذي هو في عملية الحذف ، وليس حذف المعلومات الموجودة عليه.

تضمنت النقطة 6 أثناء النشر إزالة الشيك على عدة مراحل. أولاً ، تركوا الشيك ، ثم بعد ذلك بأسبوع تم إيقاف فحص ملفات موظفي الشركة ، وبعد أسبوعين ، تم إيقاف الشيك تمامًا.

ما الذي احتجت إلى تغييره في الكود؟

مرة أخرى ، تنطبق جميع التغييرات فقط على قاعدة البيانات.

كان حجم التغييرات هو الأكبر على الخادم العالمي:
أضف جدولًا وسيطًا لإضافة جميع الملفات التي تم تنزيلها من الأجزاء.
قم بعمل JOB الذي يتحقق من الملفات الموجودة على الجدول المتوسط ​​والتي لا يتم استخدامها على أجزاء.

في قائمة انتظار الملفات المحذوفة ، أضف حقلاً بتاريخ الوصول إلى الملف آخر مرة وأضف فهرسًا.

العثور على جميع الإجراءات مع الوصول إلى الملف - اتضح 5 إجراءات. أضف إليهم كتلة تغير تاريخ آخر استخدام في قائمة الانتظار. يتغير التاريخ في كل مرة ، بغض النظر عما إذا كان قد تم ملؤه أم لا.

أضف برنامج الحذف إلى إجراءات إصدار الملف بحيث يعرض فقط الملفات التي لها تاريخ استخدام فارغ.

JOB, ( 10 , , , 2 , ) . , , . , , , .

:

في الإجراء الذي يحذف الملفات من الجدول مع الملفات المحذوفة ، كان من الضروري إضافة تحقق من عدم استخدام الملف. لقد فقد الإجراء بساطته وجماله ليس كثيرًا - في DELETE مع الإخراج ، أضافوا ببساطة ليس موجودًا.

أضفنا وظيفة JOB ، والتي في الخلفية تم ضربها من ملفات الجدول المستخدمة على الخادم.

الاختبارات

تمت إضافة سيناريوهات حول استخدام جميع خيارات التخزين إلى اختبارات التكامل.
كما كتبوا حالات جديدة لاختبار وظائف إزالة الملفات الجديدة.

أضاف Perf Lab حملاً إلى الخادم العام. بالإضافة إلى ذلك ، أضفنا حمولة مقابلة لحذف الملفات من التخزين.

انشر

. DBA , - . , .

- JOB , , .

.
, , .

S3 2 . , , .

- , , - .