مشاركة عبر


ترقية الإصدار الرئيسي في قاعدة بيانات Azure ل MySQL - خادم مرن

إشعار

تحتوي هذه المقالة على مراجع لمصطلح slave، وهو مصطلح لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، سنزيله من هذه المقالة.

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

هام

  • تختلف مدة التوقف استنادا إلى حجم مثيل قاعدة البيانات وعدد الجداول التي يحتوي عليها.
  • عند بدء ترقية إصدار رئيسي لقاعدة بيانات Azure لخادم MySQL المرن عبر Rest API أو SDK، يرجى تجنب تعديل الخصائص الأخرى للخدمة في نفس الطلب. التغييرات المتزامنة غير مسموح بها وقد تؤدي إلى نتائج غير مقصودة أو فشل في الطلب. يرجى إجراء تعديلات على الخصائص في عمليات منفصلة بعد الانتهاء من الترقية.
  • قد لا تظهر بعض أحمال العمل أداء محسنا بعد الترقية من 5.7 إلى 8.0. نقترح عليك تقييم أداء حمل العمل الخاص بك عن طريق إنشاء خادم نسخة متماثلة أولا (كخادم اختبار)، ثم ترقيته إلى خادم مستقل ثم تشغيل حمل العمل على خادم الاختبار قبل تنفيذ الترقية في بيئة إنتاج.
  • ترقية إصدار MySQL الرئيسي لا رجعة فيه. قد يفشل النشر إذا كان التحقق من الصحة يحدد تكوين الخادم بأي ميزات تتم إزالتها أو إهمالها. يمكنك إجراء تغييرات التكوين الضرورية على الخادم ومحاولة الترقية مرة أخرى.

المتطلبات الأساسية

  • يجب ترقية قراءة النسخ المتماثلة مع الإصدار 5.7 من MySQL قبل الخادم الأساسي للنسخ المتماثل لتكون متوافقة بين إصدارات MySQL المختلفة، اقرأ المزيد حول توافق النسخ المتماثل بين إصدارات MySQL.
  • قبل ترقية خوادم الإنتاج الخاصة بك، أصبح الآن أسهل وأكثر كفاءة مع ميزة التحقق من الصحة المضمنة في مدخل Microsoft Azure. تتحقق هذه الأداة مسبقا من توافق مخطط قاعدة البيانات مع MySQL 8.0، مع تمييز المشكلات المحتملة. بينما نقدم هذا الخيار المناسب، نوصي بشدة أيضا باستخدام أداة مدقق ترقية Oracle MySQL الرسمية لاختبار توافق مخطط قاعدة البيانات وإجراء اختبار الانحدار الضروري للتحقق من توافق التطبيق مع الميزات التي تم/ إزالتها في إصدار MySQL الجديد.

    إشعار

    عند استخدام أداة Oracle الرسمية للتحقق من توافق المخطط، قد تواجه بعض التحذيرات التي تشير إلى رموز مميزة غير متوقعة في الإجراءات المخزنة، مثل: mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode يمكنك تجاهل هذه التحذيرات بأمان. وهي تشير إلى الإجراءات المخزنة المضمنة مسبوقة ب mysql. والتي تستخدم لدعم ميزات Azure MySQL. لا تؤثر هذه التحذيرات على وظيفة قاعدة البيانات.

  • قم بتشغيل النسخ الاحتياطي عند الطلب قبل إجراء ترقية إصدار رئيسي على خادم الإنتاج الخاص بك، والذي يمكن استخدامه للرجوع إلى الإصدار 5.7 من النسخ الاحتياطي الكامل عند الطلب المأخوذ.
  • قبل المتابعة مع ترقية الإصدار الرئيسي، يرجى التأكد من عدم وجود معاملات XA نشطة أو معلقة على قاعدة البيانات، حيث يمكن أن تتسبب معاملات XA الجارية في فشل عملية الترقية. لتجنب هذه المشكلة، تحقق أولا من أي معاملات XA في الحالة "المعدة" عن طريق تشغيل XA RECOVER;. بالنسبة لأي معاملات تم تحديدها، استخدم XA ROLLBACK '{xid}'؛ للتراجع عن كل معاملة، واستبدال {xid} بمعرف المعاملة. تأكد من تنفيذ جميع معاملات XA أو التراجع قبل بدء الترقية للحفاظ على تناسق المعاملة وتقليل مخاطر فشل الترقية.

إجراء ترقية إصدار رئيسي مخطط لها من MySQL 5.7 إلى MySQL 8.0 باستخدام مدخل Microsoft Azure لخوادم SKU القابلة للاندفاع

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

لإجراء ترقية إصدار رئيسي لقاعدة بيانات Azure لطبقة حساب SKU القابلة للاندفاع MySQL باستخدام مدخل Microsoft Azure، اتبع الخطوات التالية:

  1. في مدخل Microsoft Azure، حدد خادم Azure Database for MySQL المرن 5.7.

    هام

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

  2. في صفحة نظرة عامة ، في شريط الأدوات، حدد ترقية.

    هام

    قبل ترقية ارتباط الزيارة لقائمة الميزات التي تمت إزالتها في MySQL 8.0. تحقق من قيم sql_mode المهملة وقم بإزالة/إلغاء تحديدها من خادم الخادم المرن 5.7 ل Azure Database for MySQL الحالي باستخدام Server Parameters Blade على مدخل Azure لتجنب فشل النشر. لم تعد sql_mode ذات القيم NO_AUTO_CREATE_USER NO_FIELD_OPTIONS NO_KEY_OPTIONS NO_TABLE_OPTIONS مدعومة في MySQL 8.0.

    لقطة شاشة تعرض Azure Database for MySQL flexible server Upgrade.

  3. التحقق من توافق المخطط

    قبل المتابعة مع الترقية، قم بتشغيل أداة مدقق ترقية MySQL الرسمية من Oracle للتحقق من أن مخطط قاعدة البيانات الحالي متوافق مع MySQL 8.0. هذه الخطوة ضرورية لضمان عملية ترقية سلسة.

  4. قرار ما قبل الترقية

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

    إشعار

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

  5. قرار ما بعد الترقية

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

    سيقوم النظام تلقائيا بترقية طبقة الحوسبة الخاصة بك من وحدة SKU القابلة للاندفاع إلى وحدة SKU للأغراض العامة المحددة التي تدعم ترقية الإصدار الرئيسي.

  6. ترقية الإصدار الرئيسي

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

    إشعار

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

  7. الارتداد التلقائي

    استنادا إلى قرار ما قبل الترقية، سيحتفظ النظام إما ب SKU للأغراض العامة أو سيعود تلقائيا إلى SKU القابل للاندفاع بعد اكتمال الترقية.

    إشعار

    إذا اخترت العودة تلقائيا إلى SKU القابل للاندفاع، فسيعود النظام إلى B2S SKU بشكل افتراضي.

إجراء ترقية إصدار رئيسي مخطط لها من MySQL 5.7 إلى MySQL 8.0 باستخدام مدخل Microsoft Azure للأغراض العامة وخوادم Business Critical SKU

لإجراء ترقية إصدار رئيسي من خادم 5.7 المرن لقاعدة بيانات Azure Database for MySQL باستخدام مدخل Microsoft Azure، قم بتنفيذ الخطوات التالية.

  1. في مدخل Microsoft Azure، حدد خادم Azure Database for MySQL المرن 5.7.

    هام

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

  2. في صفحة نظرة عامة ، في شريط الأدوات، حدد ترقية.

    هام

    قبل ترقية ارتباط الزيارة لقائمة الميزات التي تمت إزالتها في MySQL 8.0. تحقق من قيم sql_mode المهملة وقم بإزالة/إلغاء تحديدها من خادم الخادم المرن 5.7 ل Azure Database for MySQL الحالي باستخدام Server Parameters Blade على مدخل Azure لتجنب فشل النشر. لم تعد sql_mode ذات القيم NO_AUTO_CREATE_USER NO_FIELD_OPTIONS NO_KEY_OPTIONS NO_TABLE_OPTIONS مدعومة في MySQL 8.0.

    لقطة شاشة تعرض Azure Database for MySQL flexible server Upgrade.

  3. إجراء التحقق من صحة ما قبل الترقية

    قبل متابعة الترقية، حدد الزر Validate للتحقق من توافق الخادم مع MySQL 8.0.

    لقطة شاشة تظهر التحقق من الصحة.

    هام

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

  4. في الشريط الجانبي الترقية، في مربع النص إصدار MySQL لترقية، تحقق من إصدار MySQL الرئيسي الذي تريد الترقية إليه، أي 8.0.

    لقطة شاشة تعرض الترقية.

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

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

    لقطة شاشة تعرض الترقية.

    في قراءة النسخة المتماثلة والخوادم المستقلة، يتم تمكين الترقية بشكل افتراضي.

إجراء ترقية إصدار رئيسي مخطط لها من MySQL 5.7 إلى MySQL 8.0 باستخدام Azure CLI

لتنفيذ ترقية إصدار رئيسي من خادم 5.7 المرن لقاعدة بيانات Azure Database for MySQL باستخدام Azure CLI، قم بتنفيذ الخطوات التالية.

  1. قم بتثبيت Azure CLI لنظام التشغيل Windows أو استخدم Azure CLI في Azure Cloud Shell لتشغيل أوامر الترقية.

    تتطلب هذه الترقية الإصدار 2.40.0 أو أحدث من Azure CLI. إذا كنت تستخدم Azure Cloud Shell، فإن أحدث إصدار مثبت بالفعل. يُرجى تشغيل إصدار az للوصول إلى الإصدار والمكتبات التابعة التي تم تثبيتها. للتحديث لآخر إصدار، يُرجى تشغيل تحديث az.

  2. بعد تسجيل الدخول، قم بتشغيل الأمر az mysql server upgrade .

    az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version 8
    
  3. ضمن موجه التأكيد، اكتب y للتأكيد أو n لإيقاف عملية الترقية، ثم اضغط على Enter.

إجراء ترقية إصدار رئيسي من MySQL 5.7 إلى MySQL 8.0 على خادم نسخة متماثلة للقراءة باستخدام مدخل Microsoft Azure

لتنفيذ ترقية إصدار رئيسي من خادم خادم 5.7 المرن لقاعدة بيانات Azure Database for MySQL إلى MySQL 8.0 على نسخة متماثلة للقراءة باستخدام مدخل Microsoft Azure، قم بتنفيذ الخطوات التالية.

  1. في مدخل Microsoft Azure، حدد خادم النسخة المتماثلة المرن ل Azure Database for MySQL 5.7.

  2. في صفحة نظرة عامة ، في شريط الأدوات، حدد ترقية.

هام

قبل ترقية ارتباط الزيارة لقائمة الميزات التي تمت إزالتها في MySQL 8.0. تحقق من قيم sql_mode المهملة وأزلها/ألغ تحديدها من خادم الخادم المرن 5.7 ل Azure Database for MySQL الحالي باستخدام Server Parameters Blade على مدخل Azure لتجنب فشل النشر.

  1. في قسم الترقية، حدد ترقية لترقية خادم النسخ المتماثل المرن ل Azure Database for MySQL 5.7 إلى MySQL 8.0.

    يظهر إعلام لتأكيد نجاح الترقية.

  2. في صفحة نظرة عامة ، تأكد من أن خادم النسخ المتماثل المرن لقراءة خادم Azure Database for MySQL يعمل بالإصدار 8.0.

  3. الآن، انتقل إلى الخادم الأساسي وقم بإجراء ترقية الإصدار الرئيسي عليه.

إجراء الحد الأدنى من ترقية الإصدار الرئيسي لوقت التعطل من MySQL 5.7 إلى MySQL 8.0 باستخدام النسخ المتماثلة للقراءة

لتنفيذ ترقية إصدار رئيسي من خادم خادم 5.7 المرن لقاعدة بيانات Azure Database for MySQL إلى MySQL 8.0 مع الحد الأدنى من وقت التعطل باستخدام خوادم النسخ المتماثلة للقراءة، قم بتنفيذ الخطوات التالية.

  1. في مدخل Microsoft Azure، حدد خادم Azure Database for MySQL المرن 5.7.

  2. إنشاء نسخة متماثلة للقراءة من الخادم الأساسي.

  3. ترقية النسخة المتماثلة للقراءة إلى الإصدار 8.0.

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

  5. تحقق من حالة النسخ المتماثل للتأكد من أن النسخة المتماثلة قد اشتعلت مع الأساسي بحيث تكون جميع البيانات متزامنة وأنه لا يتم تنفيذ عمليات جديدة على الأساسي.

  6. تأكيد الأمر إظهار حالة النسخة المتماثلة على خادم النسخة المتماثلة لعرض حالة النسخ المتماثل.

     SHOW SLAVE STATUS\G
    

    إذا كانت حالة Slave_IO_Running Slave_SQL_Running نعم وقيمة Seconds_Behind_Master هي 0، فإن النسخ المتماثل يعمل بشكل جيد. يشير Seconds_Behind_Master إلى مدى تأخر النسخة المتماثلة. إذا لم تكن القيمة 0، فإن النسخة المتماثلة لا تزال تعالج التحديثات. بعد التأكد من أن قيمة Seconds_Behind_Master هي ***، من الآمن إيقاف النسخ المتماثل.

  7. ترقية النسخة المتماثلة للقراءة إلى الأساسية عن طريق إيقاف النسخ المتماثل.

  8. قم بتعيين Server Parameter read_only إلى 0 (OFF) لبدء الكتابة على الأساسي الذي تمت ترقيته.

  9. أشر إلى التطبيق الخاص بك إلى النسخة المتماثلة الأساسية الجديدة (النسخة المتماثلة السابقة) التي تعمل على الخادم 8.0. يحتوي كل خادم على سلسلة اتصال فريدة. حدّث التطبيق للإشارة إلى النسخة المتماثلة (السابقة) بدلًا من المصدر.

إشعار

لا يتحمل هذا السيناريو سوى وقت تعطل أثناء الخطوات من 4 إلى 7.

الأسئلة الشائعة

  • هل سيؤدي ذلك إلى وقت تعطل الخادم وإذا كان الأمر كذلك، فكم من الوقت؟

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

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

    ستستعيد جميع النسخ الاحتياطية (التلقائية/عند الطلب) التي تم أخذها قبل ترقية الإصدار الرئيسي، عند استخدامها للاستعادة دائما إلى خادم بإصدار أقدم (5.7). ستتم استعادة جميع النسخ الاحتياطية (التلقائية/عند الطلب) التي تم أخذها بعد ترقية الإصدار الرئيسي إلى الخادم مع إصدار تمت ترقيته (8.0). يوصى بشدة بأخذ نسخة احتياطية عند الطلب قبل إجراء ترقية الإصدار الرئيسي للرجوع إلى الحالة السابقة بسهولة.

  • أنا أستخدم SKU القابل للاندفاع حاليا، هل تخطط Microsoft لدعم ترقية الإصدار الرئيسي لوحدة SKU هذه في المستقبل؟

    SKU القابل للاندفاع غير قادر على دعم ترقية الإصدار الرئيسي بسبب قيود الأداء ل SKU هذا.

    إذا كنت بحاجة إلى إجراء ترقية إصدار رئيسي على مثيل خادم Azure Database for MySQL المرن وتستخدم حاليا SKU القابل للاندفاع، فسيكون أحد الحلول المؤقتة هو الترقية إلى General Purpose أو Business Critical SKU، وإجراء الترقية، ثم التبديل مرة أخرى إلى SKU القابل للاندفاع.

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