ترحيل التطبيق

مكتمل

ما إن تُنفِذ ترحيل قاعدة البيانات من قاعدة البيانات المحلية إلى Azure، حتى تحتاج إلى تحديث التطبيقات الموجودة حتى تتمكن من الوصول إلى قاعدة بيانات MySQL في موقعها الجديد.

سيحتوي الخادم وقاعدة البيانات الأصليان المحليان على أدوار تحدد الامتيازات المقترنة بالمستخدمين والعمليات التي يمكنهم القيام بها والكائنات التي يقومون بتنفيذها عبر هذه العمليات. تستخدم Azure Database for MySQL نفس آليات المصادقة والتفويض مع تشغيل PostgreSQL تشغيلاً محليًا.

في هذه الوحدة، سوف تستكشف التحديثات التي تحتاج إلى إجرائها على تطبيقاتك للاتصال بقاعدة بيانات Azure Database for MySQL المُرحَّلة حديثًا.

إنشاء المستخدمين يدويًا

سوف تضم قاعدة البيانات والخادم المحليان الأصليان: المستخدمين والعمليات التي يقومون بتنفيذها والكائنات التي يقومون عن طريقها بتلك العمليات. تستخدم قاعدة البيانات Azure Database for MySQL نفس آليات المصادقة والتفويض المُستخدَمة في قاعدة MySQL المُشغَّلة محليًا.

عند نقل قاعدة بيانات MySQL إلى قاعدة بيانات Azure Database for MySQL باستخدام خدمة ترحيل قاعدة بيانات Azure، لا يتم نسخ المستخدمين. يجب عليك يدويًا إعادة إنشاء حسابات المستخدم الضرورية للمسؤول ومستخدمي الجداول في قاعدة البيانات الهدف. للقيام بهذه المهام، يمكنك استخدام لغة SQL أو أداة مثل MySQL Workbench. قم بتشغيل الأمر CREATE USER. يمكنك استخدام الأمر GRANT لتعيين الامتيازات الضرورية لأحد المُستخدَمين. على سبيل المثال:

CREATE USER 'myuseraccount'@'%' IDENTIFIED BY 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE [Database Name].* TO myuseraccount;
FLUSH PRIVILEGES;

لعرض المنح الموجودة في قاعدة البيانات المحلية، قم بتشغيل عبارة SQL التالية:

USE [Database Name];

SHOW GRANTS FOR 'myuseraccount'@'%';;

إعادة تكوين التطبيقات

إعادة تكوين تطبيق للاتصال بقاعدة بيانات Azure Database for MySQL هي عملية مباشرة. ومع ذلك، من الضروري أن تقوم بإعداد استراتيجية لترحيل التطبيقات.

الاعتبارات الواجبة عند إعادة تكوين تطبيقات MySQL

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

عند ترحيل قاعدة بيانات MySQL إلى Azure، هناك بعض التفاصيل ينبغي مراعاتها:

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

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

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

إعادة تكوين تطبيق

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

ستجد معلومات الاتصال الخاصة بخدمة Azure Database for PostgreSQL في مدخل Microsoft Azure، على صفحة Connection strings لخدمة zure Database for MySQL. يوفر Azure المعلومات للعديد من لغات البرمجة الشائعة وأُطر العمل.

صورة تعرض صفحة Connection strings لعنصر Azure Database for PostgreSQL في مدخل Microsoft Azure

فتح منافذ الشبكة

كما ورد في الدرس الأول من هذه الوحدة، قاعدة البيانات Azure Database for MySQL هي خدمة محمية تعمل خلف جدار الحماية. لا يمكن للعملاء الاتصال ما لم يتم التعرف على عنوان IP الخاص بهم من قِبل الخدمة. يجب إضافة عناوين IP أو نطاقات كتلة العناوين للعملاء الذين يتم تشغيل التطبيقات التي تحتاج إلى الاتصال بقواعد البيانات الخاصة بك.

اختبار التطبيقات والتحقُّق منها

قبل التبديل بين التطبيقات والمستخدمين إلى قاعدة البيانات الجديدة، من المُهم التأكد من أنك قمت بتكوين كل شيء بشكل صحيح.

ابدأ بتطبيقات "التشغيل الجاف" وقم بتوصيل كل دور لضمان توفر الوظيفة الصحيحة.

بعد ذلك، قم بإجراء "اختبارات النقع" لتقليد العدد النموذجي للمستخدمين الذين يقومون بتشغيل أحمال عمل أعباء على نحو متزامن لفترةٍ من الوقت. راقب النظام، وتحقق من أنك خصصت موارد كافية لقاعدة بيانات Azure Database for MySQL.

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