كتاب قواعد البيانات. هندسة الوثوقية

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

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

لمن هذا الكتاب؟
, , . , . , . , , . .

, Linux/Unix, - / . , — — — . , , .

, , , . , , .

, , . , - , . , Excel, .

هيكل النشر
. . , , , . : , , , . , . !

, : (DBRE), (RE). , . DBR- , , .

, . . , . — , . , , , , , , , . .
, .

1 . , — , DBRE, — , , DBRE .

2 . , . , , — , . , .
3 . . .

4 . . , , . , .

5 6 . . , , , , , .

7 . , , DBE. — , . , , , .

8 . , ? SQL? — , .

9 . . .

10 , . , , . , .

11 . , , . , , , .

12 (), , , . , « » () , , . — .

, 13 . , .

اسنرجاع البيانات


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

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

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

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

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

المبادئ الأساسية


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

مادية أو منطقية؟


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

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

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

مستقلة أم عاملة؟


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

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

كاملة ، تدريجية وتفاضلية


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

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

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

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

اعتبارات استعادة البيانات


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

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

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

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

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

سيناريوهات الاسترداد


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

سيناريوهات الاسترداد المجدولة


ما المهام اليومية التي يمكن استعادة العمليات دمجها؟ في ما يلي القائمة التي التقينا بها غالبًا على مواقع مختلفة:

  • إنشاء عقد ومجموعات جديدة في بيئة العمليات الصناعية ؛
  • خلق بيئات مختلفة ؛
  • إجراء الاستخراج والتحويل والتحميل (استخراج وتحويل وتحميل ، ETL) ومراحل العملية التكنولوجية لمعالجة البيانات للمخازن الموضوعة بالتسلسل ؛
  • اختبار أداء.

عند تنفيذ هذه العمليات ، تأكد من تضمين عملية الاسترداد على مكدس التحكم التشغيلي. فكر في المؤشرات التالية.

  • زمن. كم من الوقت يستغرق لإكمال كل مكون والعملية برمتها؟ تفريغ؟ نسخ؟ تنفيذ السجل؟ اختبارات؟
  • الحجم. ما مقدار المساحة التي تستغرقها النسخة الاحتياطية ، والمضغوطة وغير المضغوطة؟
  • . ?

ستساعدك هذه المعلومات على تجنب مشاكل النطاق الترددي ، مما سيساعد على ضمان استقرار عملية الاسترداد.

عقد ومجموعات جديدة في بيئة تشغيل صناعية

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

نادرًا ما يتم تضمين قواعد البيانات في التحجيم التلقائي للأنظمة نظرًا لكمية الوقت التي قد تكون مطلوبة للتحميل الأولي للعقدة الجديدة ووضعها في مجموعة. ومع ذلك ، لا توجد أسباب تمنع الفريق من إنشاء جدول لإضافة العقد الجديدة بانتظام إلى الكتلة لاختبار هذه العمليات. قرد الفوضى ( http://bit.ly/2zy1qsE) - أداة تم تطويرها بواسطة Netflix تقوم بإيقاف تشغيل الأنظمة عشوائيًا ، وتتيح لك القيام بذلك بطريقة يمكنك من خلالها اختبار عملية المراقبة وإصدار الإشعارات وفرزها واستعادتها بالكامل. إذا لم تكن قد قمت بذلك بالفعل ، فيمكنك تضمين ذلك في خطة قائمة العمليات التي يجب أن يقوم بها قسم العمليات على فترات منتظمة حتى يتمكن جميع الموظفين من التعرف على الإجراء. تسمح لك هذه الإجراءات باختبار ليس فقط التعافي الكامل والتدريجي ، ولكن أيضًا تضمين النسخ المتماثل وعملية تشغيل العقدة.

إنشاء بيئات مختلفة

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

عمليات ETL وخطوط الأنابيب لمستودعات البيانات التي تقع أسفل خط الأنابيب

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

الاختبار الميداني

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

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

عند إنشاء نسخة احتياطية ، يمكنك الحصول على الكثير من البيانات التي يمكنك استخدامها للاختبار ، على سبيل المثال:

  • أحدث معرّف في تسلسل الزيادة التلقائية
  • عداد الخط للأشياء ؛
  • المجموع الاختباري لمجموعات فرعية من البيانات التي يتم إدراجها فقط وبالتالي يمكن اعتبارها غير قابلة للتغيير ؛
  • الاختبارية في ملفات تعريف المخطط.

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

مخطوطات غير مخططة


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

  • خطأ المستخدم
  • خطأ في تطبيق؛
  • توافر خدمات البنية التحتية ؛
  • أخطاء نظام التشغيل وأخطاء الأجهزة ؛
  • فشل الأجهزة ؛
  • فشل مركز البيانات.



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

أخطاء التطبيق

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

خدمات البنية التحتية

قدمنا ​​في الفصل السادس سحر خدمات إدارة البنية التحتية. لسوء الحظ ، يمكن أن تكون هذه الأنظمة مدمرة بقدر ما هي مفيدة ، مما قد يؤدي إلى عواقب واسعة النطاق تتعلق بتحرير ملف ، والإشارة إلى بيئة أخرى أو إعدادات تكوين غير صحيحة.

أخطاء نظام التشغيل وأخطاء الأجهزة

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



Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?

. , , . , . — .

, ZFS, , . RAID-, , .

فشل الأجهزة فشل

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

فشل مركز البيانات

في بعض الأحيان تؤدي مشكلات الأجهزة على مستوى الشبكة إلى أعطال في مركز البيانات. يحدث أن التحميل الزائد على الطائرات الخلفية للتخزين يسبب فشلًا متتاليًا ، كما كان الحال مع خدمات ويب Amazon في عام 2012 ( http://bit.ly/2zxSpzR ). في بعض الأحيان تؤدي الأعاصير والزلازل والكوارث الأخرى إلى فشل مراكز البيانات بأكملها. سيختبر الانتعاش اللاحق حتى أكثر استراتيجيات التعافي موثوقية للقوة.

نطاق البرنامج النصي


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

  • الفشل مترجم داخل عقدة واحدة ؛
  • فشل المجموعة بأكملها ؛
  • فشل يؤثر على مركز البيانات بأكمله أو مجموعات متعددة.

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

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

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

بالإضافة إلى النطاق ، هناك نطاق مجموعة بيانات. هنا يمكنك سرد ثلاثة خيارات ممكنة:

  • كائن واحد
  • عدة أشياء ؛
  • البيانات الوصفية لقاعدة البيانات.

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

عواقب البرنامج النصي


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

  • التأثير على SLO ، فشل التطبيق ، أثر على معظم المستخدمين.
  • التهديد SLO ، عانى بعض المستخدمين.
  • تتأثر الوظائف التي لا تهدد SLO.

عن المؤلفين


كامبل لين (لين كامبل) هو مدير أول (مدير أول) لشركة التصميم Fastly. كما كانت المؤسسة والرئيس التنفيذي لشركة PalominoDB / Blackbird ، وهي خدمة استشارية تحتفظ بقواعد بيانات للعديد من الشركات ، بما في ذلك أوباما لأمريكا ، Activision Call of Duty ، Adobe Echosign ، Technorati ، Livejournal ، و Zendesk. لديها 18 عامًا من الخبرة في تشغيل قواعد البيانات والأنظمة الموزعة القابلة للتطوير.

التخصصات شيري(Charity Majors) هو الرئيس التنفيذي والمؤسس المشارك لشركة honeycomb.io. من خلال الجمع بين دقة مجمِّعي السجلات ومقاييس سرعة السلاسل الزمنية ومرونة مقاييس أداء التطبيق (APMs) ، فإن قرص العسل هو أول خدمة تحليلية من الجيل الجديد حقًا في العالم. كانت Cheriti في السابق متخصصة في عمليات Parse / Facebook ، حيث تدير أسطولًا ضخمًا من مجموعات النسخ المتماثلة MongoDB ، بالإضافة إلى Redis و Cassandra و MySQL. عملت أيضًا بشكل وثيق مع فريق RocksDB على Facebook ، وشاركت في تطوير ونشر أول تثبيت Mongo + Rocks في العالم باستخدام واجهة برمجة تطبيقات التخزين الإضافية.

»يمكن العثور على مزيد من المعلومات حول الكتاب على موقع الناشر على الإنترنت
» المحتويات
» مقتطفات

ل Khabrozhiteley خصم 25 ٪ على القسيمة - قواعد البيانات

عند دفع النسخة الورقية من الكتاب ، يتم إرسال كتاب إلكتروني عن طريق البريد الإلكتروني.

All Articles