مشاركة عبر

النسخ الاحتياطي والاستعادة في قاعدة بيانات Azure ل MySQL - خادم مرن

  • مقالة

ينطبق على: قاعدة بيانات Azure ل MySQL - خادم مرن

تقوم قاعدة بيانات Azure لخادم MySQL المرن تلقائيا بإنشاء نسخ احتياطية للخادم وتخزينها بأمان في التخزين المحلي المتكرر داخل المنطقة. يمكن استخدام النسخ الاحتياطية لاستعادة الخادم الخاص بك إلى نقطة زمنية. يشكل النَسْخ الاحتياطي والاستعادة جزءاً أساسيّاً من أي إستراتيجية لاستمرارية الأعمال لأنها تحمي بياناتك من التلف العرضي أو الحذف.

نظرة عامة على النسخ الاحتياطي

تدعم قاعدة بيانات Azure لخادم MySQL المرن نوعين من النسخ الاحتياطية لتوفير مرونة محسنة للحفاظ على النسخ الاحتياطية للبيانات المهمة للأعمال.

النسخ الاحتياطي التلقائي

يأخذ Azure Database for MySQL Flexible Server النسخ الاحتياطية للقطات لملفات البيانات ويخزنها في تخزين محلي متكرر. يقوم الخادم أيضاً بإجراء نسخ احتياطي لسجلات العمليات ويخزنها أيضاً في التخزين المحلي الزائد. تسمح لك هذه النسخ الاحتياطية باستعادة الخادم إلى أي نقطة زمنية خلال فترة الاستبقاء للنسخ الاحتياطية التي تكونت. فترة الاحتفاظ الافتراضية للنسخ الاحتياطي سبعة أيام. يمكنك بشكل اختياري تكوين نسخة احتياطية لقاعدة البيانات من 1 إلى 35 يوماً. يتم تشفير جميع النسخ الاحتياطية باستخدام تشفير AES 256 بت للبيانات المخزنة في حال الثبات.

النسخ الاحتياطي عند الطلب

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

لا يمكن تصدير هذه الملفات من النسخ الاحتياطية. يمكن استخدام النسخ الاحتياطية فقط لعمليات الاستعادة في قاعدة بيانات Azure لخادم MySQL المرن. يمكنك أيضاً استخدام mysqldump من عميل MySQL لنسخ قاعدة بيانات.

تردد النسخ الاحتياطي

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

إشعار

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

خيارات التكرار الاحتياطية

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

يضمن تكرار النسخ الاحتياطي أن قاعدة البيانات الخاصة بك تفي بأهداف التوفر والمتانة حتى في مواجهة حالات الفشل، وقاعدة بيانات Azure لخادم MySQL المرن يوسع ثلاثة خيارات للمستخدمين -

  • تخزين النسخ الاحتياطي الفائض محلياً : عندما يتم تخزين النسخ الاحتياطية في مخزن نسخ احتياطي متكرر محلياً، يتم تخزين نسخ متعددة من النسخ الاحتياطية في نفس مركز البيانات. يحمي هذا الخيار بياناتك من حامل الخادم وعمليات فشل محرك الأقراص. هذا يوفر أيضاً قدرة على الصمود 99.999999999% (11 9's) على الأقل لعناصر النسخ الاحتياطية على مدار عام معين. بشكل افتراضي، يتم تعيين تخزين النسخ الاحتياطي للخوادم ذات قابلية الوصول العالية في نفس المنطقة (HA) أو تكوين عديم قابلية الوصول العالية إلى متكرر محلياً.

  • تخزين النسخ الاحتياطي المتكرر في المنطقة: عند تخزين النسخ الاحتياطية في تخزين النسخ الاحتياطي المتكرر في المنطقة، لا يتم تخزين نسخ متعددة فقط داخل منطقة التوفر التي تتم استضافة الخادم فيها، ولكن يتم نسخها أيضا إلى منطقة توفر أخرى في نفس المنطقة. يمكن الاستفادة من هذا الخيار للسيناريوهات التي تتطلب قابلية وصول عالية أو لتقييد النسخ المتماثل للبيانات داخل بلد/منطقة لتلبية متطلبات موقع البيانات. هذا يوفر أيضاً قدرة على الصمود 99.9999999999% (12 9's) على الأقل لعناصر النسخ الاحتياطية على مدار عام معين. يمكن للمرء تحديد خيار Zone-Redundant High Availability على الخادم لإنشاء وقت لضمان تخزين النسخ الاحتياطي في المنطقة. يمكن تعطيل التوفر العالي للخادم بعد الإنشاء، ولكن يظل تخزين النسخ الاحتياطي متكررا في المنطقة.

  • تخزين النسخ الاحتياطي الجغرافي المكرر: عند تخزين النسخ الاحتياطية في تخزين النسخ الاحتياطي المتكرر جغرافيا، لا يتم تخزين نسخ متعددة داخل المنطقة التي تتم استضافة الخادم فيها فحسب، بل يتم نسخها أيضا إلى منطقتها المقترنة جغرافيا. يوفر هذا حماية أفضل وقدرة على استعادة الخادم الخاص بك في منطقة مختلفة في حدث وقوع كارثة. يوفر هذا أيضاً ما لا يقل عن 99.99999999999999% (16 9's) قدرة على الصمود لعناصر النسخ الاحتياطي على مدار عام معين. يمكن للمرء تمكين خيار Geo-Redundancy في الخادم لإنشاء وقت لضمان تخزين النسخ الاحتياطي المكرر جغرافياً. بالإضافة إلى ذلك، يمكنك الانتقال من التخزين المكرر محلياً إلى إنشاء خادم نشر للتخزين المكرر جغرافياً. يتم دعم التكرار الجغرافي للخوادم المستضافة في أي من مناطق Azure المقترنة.

إشعار

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

الانتقال من خيارات تخزين النسخ الاحتياطي الأخرى إلى تخزين النسخ الاحتياطي المكرر جغرافياً

يمكنك نقل تخزين النسخ الاحتياطية الموجودة لديك إلى مساحة تخزين مكررة جغرافياً باستخدام الطرق المقترحة التالية:

  • الانتقال من تخزين النسخ الاحتياطي المكرر محلياً إلى التخزين الاحتياطي المكرر جغرافياً - من أجل نقل تخزين النسخ الاحتياطي من التخزين المحلي المكرر إلى التخزين المكرر جغرافياً، يمكنك تغيير تكوين خادم Compute + Storage من مدخل Microsoft Azure لتمكين التكرار الجغرافي لخادم المصدر المكرر محلياً. يمكن أيضاً استعادة خوادم HA المتوفرة في المنطقة نفسها كخادم مكرر جغرافياً بطريقة مماثلة لأن تخزين النسخ الاحتياطي الأساسي يكون مكرراً محلياً لنفسه.

  • الانتقال من التخزين المتكرر في المنطقة إلى تخزين النسخ الاحتياطي المتكرر جغرافيا - لا تدعم قاعدة بيانات Azure لخادم MySQL المرن التخزين المتكرر في المنطقة لتحويل التخزين المتكرر جغرافيا من خلال تغيير إعدادات الحوسبة + التخزين بعد توفير الخادم. لنقل تخزين النسخ الاحتياطي من التخزين المتكرر في المنطقة إلى التخزين المتكرر جغرافيا، هناك خياران: أ) استخدام PITR (استعادة نقطة زمنية) لاستعادة الخادم بالتكوين المطلوب. ب) إنشاء خادم جديد بالتكوين المطلوب وترحيل البيانات باستخدام التفريغ والاستعادة.

استبقاء النسخ الاحتياطية

يتم استبقاء النسخ الاحتياطية بناءً على إعداد فترة الاستبقاء للنسخ الاحتياطي على الخادم. يمكنك تحديد فترة استبقاء من 1 إلى 35 يوماً مع فترة استبقاء افتراضية هي سبعة أيام. يمكنك تعيين فترة الاستبقاء أثناء إنشاء الخادم أو لاحقاً عن طريق تحديث تكوين النسخ الاحتياطي باستخدام مدخل Microsoft Azure.

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

تكلفة تخزين النسخ الاحتياطي

توفر قاعدة بيانات Azure لخادم MySQL المرن ما يصل إلى 100٪ من مساحة تخزين الخادم المتوفرة كمخزن احتياطي دون أي تكلفة إضافية. احتساب أي مساحة تخزين إضافية للنسخ الاحتياطي مستخدمة GB شهرياً. على سبيل المثال، إذا قمت بتزويد خادم بسعة تخزينية تبلغ 250 جيجابايت، فلديك 250 جيجابايت من السعة التخزينية المتاحة للنسخ الاحتياطية للخادم دون أي رسوم إضافية. إذا كان استخدام النسخ الاحتياطي اليومي 25 جيجابايت، فيمكنك الحصول على ما يصل إلى 10 أيام من التخزين الاحتياطي المجاني. يتم احتساب سعة التخزين المستهلكة للنسخ الاحتياطية التي تزيد عن 250 غيغابايت وفقاً لنموذج الأسعار.

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

تتمثل الوسيلة الأساسية للتحكم في تكلفة تخزين النسخ الاحتياطي في تحديد فترة الاستبقاء المناسبة للنسخ الاحتياطي. يمكنك تحديد فترة استبقاء تتراوح بين يوم واحد و35 يوماً.

هام

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

عرض Available Full Backups

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

استعادة

في Azure Database for MySQL Flexible Server، يؤدي إجراء استعادة إلى إنشاء خادم جديد من النسخ الاحتياطية للخادم الأصلي. يتوفر نوعان من الاستعادة:

  • الاستعادة في الوقت المناسب: متاحة مع خيار النسخ الاحتياطي المكرر وتنشئ خادماً جديداً في نفس المنطقة مثل الخادم الأصلي.
  • الاستعادة الجغرافية: تتوفر فقط إذا قمت بتكوين الخادم الخاص بك للتخزين المتكرر جغرافيا ويسمح لك باستعادة الخادم الخاص بك إما إلى منطقة مقترنة جغرافيا أو أي منطقة أخرى مدعومة من Azure حيث يتوفر Flexible Server.

يعتمد الوقت المقدر لاسترداد الخادم على عدة عوامل:

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

إشعار

سيصبح الخادم الممكن لقابلية الوصول العالية غير عالي التوفر (معطل قابلية وصول عالية) بعد الاستعادة لكل من الاستعادة في نقطة زمنية والاستعادة الجغرافية.

استعادة النقطة الزمنية

في Azure Database for MySQL Flexible Server، يؤدي إجراء استعادة في نقطة زمنية إلى إنشاء خادم جديد من النسخ الاحتياطية للخادم المرن في نفس المنطقة مثل الخادم المصدر. يتم إنشاؤه مع تكوين الخادم الأصلي لطبقة الحوسبة، وعدد vCores، وحجم التخزين، وفترة الاحتفاظ بالنسخ الاحتياطي، وخيار التكرار للنسخ الاحتياطي. أيضاً، يتم توريث العلامات والإعدادات مثل الشبكة الظاهرية وجدار الحماية من الخادم المصدر. يمكن تغيير إعدادات الحوسبة والتخزين الخاصة بالخادم المستعاد، وإعدادات التكوين والأمان بعد اكتمال الاستعادة.

إشعار

هناك معلمتان للخادم تتم إعادة تعيينهما إلى القيم الافتراضية (ولا يتم نسخهما من الخادم الأساسي) بعد عملية الاستعادة

  • time_zone - هذه القيمة المراد تعيينها إلى DEFAULT SYSTEM
  • event_scheduler - بالنسبة إلى خوادم الإصدار 5.7 من MySQL، يتم تشغيل معلمة event_scheduler الخادم تلقائيا "إيقاف التشغيل" عند بدء النسخ الاحتياطي، ويتم إعادة تشغيل معلمة event_scheduler الخادم "تشغيل" بعد اكتمال النسخ الاحتياطي بنجاح. في الإصدار 8.0 من MySQL لقاعدة بيانات Azure ل MySQL - الخادم المرن، يظل event_scheduler غير متأثر أثناء النسخ الاحتياطية. لضمان عمليات أكثر سلاسة، يوصى بترقية خوادم MySQL 5.7 إلى الإصدار 8.0 باستخدام ترقية إصدار رئيسي.

تعد الاستعادة في الوقت المناسب مفيدة في سيناريوهات متعددة. تتضمن بعض حالات الاستخدام الشائعة -

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

يمكنك الاختيار بين أحدث نقطة استعادة ونقطة استعادة مخصصة وأسرع نقطة استعادة (استعادة باستخدام نسخة احتياطية كاملة) عبر مدخل Microsoft Azure.

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

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

هام

إذا كنت تستعيد مثيل Azure Database for MySQL Flexible Server الذي تم تكوينه مع توفر عال متكرر للمنطقة، يتم تكوين الخادم المستعادة في نفس المنطقة والمنطقة مثل الخادم الأساسي، ويتم نشره كخادم واحد في وضع غير HA. راجع قابلية الوصول العالية الزائدة عن الحاجة للمنطقة للخادم المرن.

هام

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

الاستعادة الجغرافية

يمكنك استعادة خادم إلى منطقته المقترنة جغرافيا حيث تتوفر الخدمة إذا قمت بتكوين الخادم الخاص بك للنسخ الاحتياطية المتكررة جغرافيا أو أي منطقة أخرى مدعومة من Azure حيث تتوفر قاعدة بيانات Azure لخادم MySQL المرن. القدرة على الاستعادة إلى أي منطقة مدعومة من Azure غير مقترنة (باستثناء Brazil South، West US 3) USGov Virginia وتعرف باسم "الاستعادة الجغرافية العالمية".

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

يمكن أيضاً إجراء الاستعادة الجغرافية على خادم متوقف يستفيد من Azure CLI. اقرأ استعادة قاعدة بيانات Azure لخادم MySQL المرن باستخدام Azure CLI لمعرفة المزيد حول الاستعادة الجغرافية لخادم باستخدام Azure CLI.

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

إشعار

إذا كنت تقوم بالاستعادة الجغرافية لمثيل Azure Database for MySQL Flexible Server الذي تم تكوينه مع توفر عال متكرر للمنطقة، يتم تكوين الخادم المستعاد في المنطقة المقترنة جغرافيا والمنطقة نفسها مثل الخادم الأساسي ونشره كمثيل Azure Database for MySQL Flexible Server في وضع غير HA. راجع التوفر العالي المتكرر للمنطقة لقاعدة بيانات Azure لخادم MySQL المرن.

هام

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

تنفيذ مهام ما بعد الاستعادة

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

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

الاستبقاء طويل المدى (معاينة)

قامت خدمات Azure Backup وAzure Database for MySQL Flexible Server بإنشاء حل نسخ احتياطي طويل الأجل على مستوى المؤسسة لمثيلات Azure Database for MySQL Flexible Server التي تحتفظ بالنسخ الاحتياطية لمدة تصل إلى 10 سنوات. يمكنك استخدام الاستبقاء طويل الأجل بشكل مستقل أو بالإضافة إلى حل النسخ الاحتياطي التلقائي الذي توفره قاعدة بيانات Azure لخادم MySQL المرن، والذي يوفر الاحتفاظ لمدة تصل إلى 35 يوما. النسخ الاحتياطية التلقائية هي نسخ احتياطية للقطة مناسبة لعمليات الاسترداد التشغيلية، خاصة عندما تريد الاستعادة من أحدث النسخ الاحتياطية. تساعدك النسخ الاحتياطية طويلة المدى على تلبية احتياجات التوافق واحتياجات التدقيق. بالإضافة إلى الاستبقاء طويل الأجل، يوفر الحل الإمكانات التالية:

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

تحديد الخدمة واعتباراتها

  • في المعاينة، تتوفر استعادة LTR حاليا ك RestoreasFiles لحسابات التخزين. ستتم إضافة إمكانية RestoreasServer في المستقبل.
  • دعم إنشاء LTR وإدارته من خلال Azure CLI غير مدعوم حاليا.

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

النسخ الاحتياطي والتصدير عند الطلب (معاينة)

توفر قاعدة بيانات Azure لخادم MySQL المرن الآن القدرة على تشغيل نسخة احتياطية فعلية عند الطلب للخادم في الوقت الحالي وتصديرها إلى حساب تخزين Azure (تخزين Azure blob). بمجرد تصديرها، يمكن استخدام هذه النسخ الاحتياطية لاسترداد البيانات والترحيل والتكرار. يمكن استخدام ملفات النسخ الاحتياطي الفعلية المصدرة هذه للاستعادة مرة أخرى إلى خادم MySQL داخلي للمساعدة في تلبية احتياجات التدقيق/التوافق/الأرشفة للمؤسسة. الميزة حاليا في المعاينة العامة ومتاحة فقط في مناطق السحابة العامة.

لمزيد من المعلومات حول تصدير النسخ الاحتياطي، تفضل بزيارة دليل الكيفية

الأسئلة المتداولة (FAQs)

  • كيف أعمل النسخ الاحتياطي لخادمي؟

    بشكل افتراضي، تتيح قاعدة بيانات Azure لخادم MySQL المرن النسخ الاحتياطية التلقائية للخادم بأكمله (بما في ذلك جميع قواعد البيانات التي تم إنشاؤها) مع فترة استبقاء افتراضية مدتها 7 أيام. يمكنك أيضا تشغيل نسخة احتياطية يدوية باستخدام ميزة النسخ الاحتياطي عند الطلب. الطريقة الأخرى لأخذ نسخة احتياطية يدويا هي باستخدام أدوات المجتمع مثل mysqldump كما هو موثق هنا أو mydumper كما هو موثق هنا. إذا كنت ترغب في إجراء نسخ احتياطي لمثيل Azure Database for MySQL Flexible Server إلى تخزين Blob، فراجع مدونة مجتمعنا التقني النسخ الاحتياطي لقاعدة بيانات Azure لخادم MySQL المرن إلى Blob Storage.

  • هل يمكنني تكوين النسخ الاحتياطية التلقائية ليتم الاحتفاظ بها على المدى الطويل؟

    لا، لا ندعم حالياً سوى 35 يوماً كحد أقصى لاستبقاء النسخ الاحتياطي الآلي. يمكنك أخذ نسخ احتياطية يدوية واستخدامها لمتطلبات الاستبقاء طويل المدى.

  • ما هي نوافذ النسخ الاحتياطي لخادمي؟ هل يمكنني تخصيصه؟

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

  • هل النسخ الاحتياطية مشفرة؟

    يتم تشفير جميع بيانات Azure Database for MySQL Flexible Server والنسخ الاحتياطية والملفات المؤقتة التي تم إنشاؤها أثناء تنفيذ الاستعلام باستخدام تشفير AES 256 بت. تشفير التخزين قيد التشغيل دائما ولا يمكن تعطيله.

  • هل يمكنني استعادة قاعدة (قواعد) بيانات واحدة/قليلة؟

    استعادة قاعدة (قواعد) بيانات واحدة/قليلة أو جداول غير مدعومة. إذا كنت ترغب في استعادة قواعد بيانات معينة، فقم بإجراء Point في Time Restore ثم استخرج الجدول (الجداول) أو قاعدة (قواعد) البيانات المطلوبة.

  • هل الخادم الخاص بي متوفر أثناء نافذة النسخ الاحتياطي؟

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

  • عند إعداد نافذة الصيانة للخادم، هل نحتاج إلى حساب نافذة النسخ الاحتياطي؟

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

  • أين يتم تخزين النسخ الاحتياطية التلقائية وكيف يمكنني إدارة استبقائها؟

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

  • كيف يمكنني التحقق من صحة النسخ الاحتياطية؟

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

  • أين يمكنني رؤية استخدام النسخ الاحتياطي؟

    في مدخل Microsoft Azure، ضمن علامة التبويب Monitoring - Metrics، يمكنك العثور على مقياس Backup Storage Used ، والذي يمكن أن يساعدك في مراقبة إجمالي استخدام النسخ الاحتياطي.

  • ماذا يحدث للنسخ الاحتياطية الخاصة بي إذا حذفت الخادم؟

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

  • ماذا يحدث للنسخ الاحتياطية عند استعادة خادم؟

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

  • كيف يتم تحصيل الرسوم والفواتير مقابل استخدامي للنسخ الاحتياطية؟

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

  • كيف يتم الاحتفاظ بالنسخ الاحتياطية للخوادم المتوقفة؟

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

  • كيف ستتم فوترة النسخ الاحتياطية لخادم متوقف؟

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

  • كيف تتم حماية بيانات النسخ الاحتياطي؟

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

  • كيف تؤثر عملية الاستعادة في نقطة زمنية (PITR) على استخدام IOPS؟

    أثناء عملية PITR في قاعدة بيانات Azure ل MySQL - خادم مرن، يتم إنشاء خادم جديد ونسخ البيانات من تخزين الخادم المصدر إلى تخزين الخادم الجديد. تؤدي هذه العملية إلى زيادة استخدام IOPS على الخادم المصدر. هذه الزيادة في استخدام IOPS هي تكرار عادي ولا تشير إلى أي مشكلات في الخادم المصدر أو عملية PITR. بمجرد اكتمال عملية PITR، سيعود استخدام IOPS على الخادم المصدر إلى مستوياته المعتادة.

  • كيف يمكنني استعادة الخادم الخاص بي؟ يدعم مدخل Microsoft Azure استعادة نقطة زمنية لجميع الخوادم، ما يسمح للمستخدمين بالاستعادة إلى أحدث نقاط الاستعادة أو المخصصة. لاستعادة الخادم يدويا من النسخ الاحتياطية التي تم التقاطها بواسطة mysqldump/myDumper، راجع استعادة قاعدة البيانات باستخدام myLoader.

  • لماذا تستغرق استعادتي وقتا طويلا؟

    يعتمد الوقت المقدر لاسترداد الخادم على عدة عوامل:

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

  • هل سيؤثر تعديل متغيرات قاعدة البيانات على مستوى جلسة العمل على الاستعادة؟

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

الخطوات التالية