البرامج النصية المنشورة المحسنة للقطة متسقة لقاعدة البيانات
توفر خدمة Azure Backup بالفعل إطار عمل البرنامج النصي المسبق لتحقيق تناسق التطبيق في أجهزة Linux الظاهرية باستخدام Azure Backup. تتضمن هذه العملية استدعاء برنامج نصي مسبق (لإلغاء تنشيط التطبيقات) قبل أخذ لقطة من الأقراص واستدعاء البرنامج النصي اللاحق (أوامر لإلغاء تجميد التطبيقات) بعد اكتمال اللقطة لإرجاع التطبيقات إلى الوضع العادي.
قد يكون تأليف وتصحيح وصيانة البرامج النصية الإلكترونية السابقة / اللاحقة أمراً صعباً. لإزالة هذا التعقيد، يوفر Azure Backup تجربة مبسطة قبل / بعد البرنامج النصي لقواعد بيانات الشاشة الاسمية للحصول على لقطة متسقة للتطبيق بأقل عبء.
يحتوي إطار عمل البرنامج النصي المحسن الجديد قبل ما بعد على الفوائد الرئيسية التالية:
- يتم تثبيت هذه البرامج النصية قبل النشر مباشرة في أجهزة Azure الظاهرية إلى جانب ملحق النسخ الاحتياطي، مما يساعد على التخلص من التأليف وتنزيلها من موقع خارجي.
- يمكنك عرض تعريف ومحتوى البرامج النصية قبل النشر في GitHub، حتى إرسال الاقتراحات والتغييرات. يمكنك حتى إرسال الاقتراحات والتغييرات عبر GitHub، والتي سيتم فرزها وإضافتها لصالح المجتمع الأوسع.
- يمكنك حتى إضافة برامج نصية جديدة قبل النشر لقواعد البيانات الأخرى عبر GitHub، والتي سيتم فرزها ومعالجتها لفائدة المجتمع الأوسع.
- يعتبر إطار العمل القوي فعالاً في التعامل مع السيناريوهات، مثل فشل تنفيذ البرنامج النصي أو الأعطال. في أي حال، يتم تشغيل ما بعد النص تلقائياً للتراجع عن جميع التغييرات التي تم إجراؤها في النص المسبق.
- يوفر إطار العمل أيضا قناة مراسلة للأدوات الخارجية لجلب التحديثات وإعداد خطة العمل الخاصة بها على أي رسالة/حدث.
تدفق الحل
مصفوفة الدعم
يغطي الإطار المحسن قائمة قواعد البيانات التالية:
- Oracle (متوفر بشكل عام) - ارتباط لمصفوفة الدعم
- MySQL (معاينة)
المتطلبات الأساسية
ما عليك سوى تعديل ملف تكوين باسم workload.conf في /etc/azure
لتوفير تفاصيل الاتصال. يسمح هذا لـ Azure Backup بالاتصال بالتطبيق ذي الصلة وتنفيذ البرامج النصية المسبقة واللاحقة. ملف التكوين يحتوي على المعلمات التالية.
[workload]
# valid values are mysql, oracle
workload_name =
command_path =
linux_user =
credString =
ipc_folder =
timeout =
يصف الجدول التالي المعلمات:
المعلمة | إلزامي | الشرح |
---|---|---|
اسم_حجم العمل | نعم | سيحتوي هذا على اسم قاعدة البيانات التي تحتاج إلى نسخة احتياطية متسقة من التطبيق. القيم المدعومة الحالية هي oracle أو mysql . |
command_path/configuration_path | سيحتوي هذا على مسار ثنائي لعبء العمل. هذا ليس حقلا إلزاميا إذا تم تعيين ثنائي حمل العمل كمتغير مسار. | |
linux_user | نعم | سيحتوي هذا على اسم مستخدم Linux مع إمكانية الوصول إلى تسجيل دخول مستخدم قاعدة البيانات. إذا لم يتم تعيين هذه القيمة، فسيتم اعتبار الجذر هو المستخدم الافتراضي. |
credString | يشير هذا إلى سلسلة بيانات الاعتماد للاتصال بقاعدة البيانات. سيحتوي هذا على سلسلة تسجيل الدخول بأكملها. | |
ipc_folder | يمكن لحمل العمل الكتابة فقط إلى مسارات نظام ملفات معينة. تحتاج إلى توفير مسار هذا المجلد هنا حتى يتمكن البرنامج النصي المسبق من كتابة الحالات إلى مسار المجلد هذا. | |
المهلة | نعم | هذا هو الحد الأقصى للوقت الذي ستكون فيه قاعدة البيانات في حالة الهدوء. القيمة الافتراضية 90 ثانية. لا يوصى بتعيين قيمة أقل من 60 ثانية. |
إشعار
تعريف JSON هو قالب قد تعدله خدمة Azure Backup ليناسب قاعدة بيانات معينة. لفهم ملف التكوين لكل قاعدة بيانات، راجع دليل كل قاعدة بيانات.
التجربة الكلية لاستخدام إطار عمل البرنامج النصي المحسن لما قبل النشر هي كما يلي:
- تحضير بيئة قاعدة البيانات
- قم بتحرير ملف التكوين
- قم بتشغيل النسخ الاحتياطي للجهاز الافتراضي
- قم باستعادة الأجهزة الافتراضية أو الأقراص / الملفات من نقطة الاسترداد المتوافقة للتطبيق كما هو مطلوب.
بناء إستراتيجية النسخ الاحتياطي لقاعدة البيانات
استخدام اللقطات بدلاً من البث
عادةً ما يتم استخدام النسخ الاحتياطية المتدفقة (مثل النسخ الاحتياطية الكاملة أو التفاضلية أو المتزايدة) والسجلات بواسطة مسؤولي قاعدة البيانات في إستراتيجية النسخ الاحتياطي الخاصة بهم. فيما يلي بعض المحاور الرئيسية في التصميم.
- الأداء والتكلفة: ستكون السجلات + الكاملة اليومية هي الأسرع أثناء الاستعادة ولكنها تنطوي على تكلفة كبيرة. يؤدي تضمين نوع النسخ الاحتياطي المتدفق التفاضلي / المتزايد إلى تقليل التكلفة ولكنه قد يؤثر على أداء الاستعادة. لكن اللقطات توفر أفضل مزيج من الأداء والتكلفة. نظراً لأن اللقطات تكون تدريجية بطبيعتها، فإن لها أقل تأثير على الأداء أثناء النسخ الاحتياطي، وتتم استعادتها بسرعة، كما توفر التكلفة.
- التأثير على قاعدة البيانات/البنية الأساسية: يعتمد أداء النسخ الاحتياطي المتدفق على عمليات الإدخال والإخراج في الثانية للتخزين الأساسي وعرض النطاق الترددي للشبكة المتوفر عند استهداف الدفق إلى موقع بعيد. لا تتمتع اللقطات بهذه التبعية، ويتم تقليل الطلب على IOPS وعرض النطاق الترددي للشبكة بشكل كبير.
- إعادة الاستخدام: تختلف أوامر تشغيل أنواع النسخ الاحتياطي المتدفقة المختلفة لكل قاعدة بيانات. لذلك، لا يمكن إعادة استخدام البرامج النصية بسهولة. أيضاً، إذا كنت تستخدم أنواعاً مختلفة من النسخ الاحتياطية، فتأكد من تقييم سلسلة التبعية للحفاظ على دورة الحياة. بالنسبة إلى اللقطات، من السهل كتابة البرنامج النصي حيث لا توجد سلسلة تبعية.
- الاستبقاء طويل الأجل: النسخ الاحتياطية الكاملة مفيدة دائما للاحتفاظ بها على المدى الطويل0 حيث يمكن نقلها واستردادها بشكل مستقل. ولكن، بالنسبة لعمليات النسخ الاحتياطي التشغيلي مع الاحتفاظ قصير المدى، تكون اللقطات مواتية.
لذلك، فإن اللقطات اليومية + السجلات مع النسخ الاحتياطي الكامل العرضي للاحتفاظ طويل الأمد هي أفضل سياسة نسخ احتياطي لقواعد البيانات.
سجل إستراتيجية النسخ الاحتياطي
تم بناء إطار عمل البرنامج النصي المحسن قبل النشر على النسخ الاحتياطي Azure VM الذي يقوم بجدولة النسخ الاحتياطي مرة واحدة يومياً. لذلك، فإن نافذة فقدان البيانات مع هدف نقطة الاسترداد (RPO) ك 24 ساعة غير مناسبة لقواعد بيانات الإنتاج. يتم استكمال هذا الحل بإستراتيجية النسخ الاحتياطي للسجل حيث يتم بث النسخ الاحتياطية للسجلات بشكل صريح.
يساعد NFS على blob وNFS على AFS (معاينة) في سهولة تحميل وحدات التخزين مباشرة على أجهزة قاعدة البيانات الظاهرية واستخدام عملاء قاعدة البيانات لنقل النسخ الاحتياطية للسجل. نافذة فقدان البيانات التي هي RPO، تقع في تكرار النسخ الاحتياطية للسجل. أيضاً، لا تحتاج أهداف NFS إلى أن تكون عالية الأداء حيث قد لا تحتاج إلى تشغيل تدفق منتظم (كامل ومتزايد) للنسخ الاحتياطية التشغيلية بعد أن يكون لديك لقطات متسقة لقاعدة البيانات.
إشعار
عادةً ما يهتم البرنامج النصي المحسّن بمسح جميع معاملات السجل أثناء الانتقال إلى وجهة النسخ الاحتياطي للسجل، قبل إيقاف قاعدة البيانات لأخذ لقطة. لذلك، فإن اللقطات هي قاعدة بيانات متسقة وموثوقة أثناء الاسترداد.
إستراتيجية الاسترداد
بمجرد أخذ اللقطات المتسقة لقاعدة البيانات وتدفق النسخ الاحتياطية للسجل إلى وحدة تخزين NFS، يمكن أن تستخدم إستراتيجية الاسترداد لقاعدة البيانات وظيفة الاسترداد الخاصة بنسخ Azure VM الاحتياطية. بالإضافة إلى ذلك، يتم تطبيق إمكانية النسخ الاحتياطية للسجل عليها باستخدام عميل قاعدة البيانات. فيما يلي بعض الخيارات لإستراتيجية الاسترداد:
- إنشاء أجهزة ظاهرية جديدة من نقطة استرداد متسقة لقاعدة البيانات. يجب أن يكون الجهاز الظاهري متصلاً بالفعل بنقطة تثبيت السجل. استخدم عملاء قاعدة البيانات لتشغيل أوامر الاسترداد للاسترداد في وقت واحد.
- قم بإنشاء أقراص من نقطة استرداد متسقة لقاعدة البيانات وقم بإرفاقها بجهاز افتراضي آخر مستهدف. ثم قم بتركيب وجهة السجل واستخدم عملاء قاعدة البيانات لتشغيل أوامر الاسترداد لاسترداد نقطة في الوقت المناسب
- استخدم خيار استرداد الملفات وقم بإنشاء برنامج نصي. قم بتشغيل البرنامج النصي على الجهاز الظاهري المستهدف وإرفاق نقطة الاسترداد كأقراص iSCSI. ثم استخدم عملاء قاعدة البيانات لتشغيل وظائف التحقق من الصحة الخاصة بقاعدة البيانات على الأقراص المرفقة والتحقق من صحة بيانات النسخ الاحتياطي. أيضاً، استخدم عملاء قاعدة البيانات لتصدير / استرداد بعض الجداول / الملفات بدلاً من استعادة قاعدة البيانات بأكملها.
- استخدم وظيفة الاستعادة عبر المناطق لتنفيذ الإجراءات المذكورة أعلاه من المنطقة المقترنة الثانوية أثناء كارثة إقليمية.
الملخص
باستخدام اللقطات المتسقة لقاعدة البيانات + السجلات التي تم نسخها احتياطياً باستخدام حل مخصص، يمكنك إنشاء حل نسخ احتياطي لقاعدة البيانات فعال ومنخفض التكلفة يستفيد من مزايا النسخ الاحتياطي لـ Azure VM وأيضاً إعادة استخدام قدرات عملاء قاعدة البيانات.