دورة الحياة

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

إجراء تبديل

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

يتم إجراء التبديل باتباع الإجراءات القياسية (راجع المحول في Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery وSOA Suite على Oracle Cloud Infrastructure Marketplace Disaster Recovery.).

1. نشر أية تغييرات تكوين معلقة لكل خطوات مقدمة في "إعداد استنساخ التكوين الجاري".
2. إيقاف الخوادم في الموقع الأساسي.
3. أسماء DNS الخاصة بالتبديل.
4. تبديل قاعدة البيانات.
5. بدء الخوادم في الموقع الثانوي.

الفرق الرئيسي هو أنه يتم استخدام وحدة تحكم Oracle Cloud Infrastructure (OCI) فقط لتبديل مثيل Oracle Autonomous Database.

ملاحظة:

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

قم بتنفيذ الخطوات التالية لعملية التبديل:

1. تعطيل أي استنساخ مجدول أثناء إجراء التبديل، حيث قد يفشل ويتداخل مع عملية التبديل نفسها.
2. إيقاف الخوادم في الموقع الأساسي.
   استخدم وحدة تحكم أو اسكربتات Oracle WebLogic Administration Server لإيقاف طبعات Oracle WebLogic Server في الموقع الأساسي.

   ملاحظة:

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

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

   بالنسبة للسيناريوهات التي يتم فيها استخدام DNS لحل الواجهة الأمامية الخارجية (مثل OCI DNS أو DNS التجاري)، يمكنك استخدام واجهة برمجة تطبيقات لدفع التغيير. للاطلاع على مثال يدفع هذا التغيير في OCI DNS، انتقل إلى GitHub على سبيل المثال البرامج النصية لتحديث DNS الخاص بالواجهة الأمامية.

   ملاحظة:

   ستؤثر قيمة TTL الخاصة بإدخال DNS على RTO الخاص بالمحول: إذا كانت قيمة TTL عالية (على سبيل المثال، 20 دقيقة)، فإن تغيير DNS سيستغرق ذلك الوقت لتكون فعالة في العملاء. يؤدي استخدام قيم TTL المنخفضة إلى تسريع هذه العملية؛ ومع ذلك، قد يتسبب ذلك في حدوث نفقات إضافية لأن العملاء سيضربون DNS بشكل متكرر بدلاً من استخدام الأسماء المخزنة مؤقتًا. النهج الجيد هو تعيين قيمة وقت استمرار الفاعلية إلى قيمة منخفضة مؤقتًا (على سبيل المثال، دقيقة واحدة) قبل التغيير في DNS. ثم قم بإجراء التغيير، وبمجرد اكتمال إجراء التحويل، قم بإرجاع قيمة TTL إلى قيمتها الأصلية مرة أخرى.
4. سجل الدخول إلى وحدة تحكم Oracle Cloud Infrastructure (OCI) الخاصة بـ SECONDARY REGION، ثم انتقل إلى Autonomous Database.
5. حدد الحاوية التي تستضيف قاعدة بيانات Oracle WebLogic وانقر على اسم قاعدة البيانات.
6. حدد تبديل من القائمة المنسدلة مزيد من الإجراءات، ثم تأكد من إدخال اسم قاعدة البيانات البديلة.
7. انتظر حتى اكتمال العملية.

   تظهر الحالة في قائمة "طلبات العمل" أسفل "الموارد" على اليسار.

8. قم ببدء تشغيل خادم الإدارة الثانوي (أو أعد التشغيل إذا كان قد تم بدؤه بالفعل، ولذا فإن تغييرات التكوين التي تم نسخها أثناء سريان مفعول هذا الإعداد البديل.)
9. بدء الخوادم المدارة الثانوية (باستخدام وحدة تحكم أو اسكربتات Oracle WebLogic Server).

تنفيذ انتقال تلقائي

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

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

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

1. إن أمكن، أوقف خوادم WebLogic في الموقع الأساسي.
2. تبديل أسماء DNS.
3. تجاوز فشل قاعدة البيانات.

   ملاحظة:

   عند استخدام Oracle Autonomous Database Serverless، يظهر ارتباط الانتقال التلقائي فقط عند عدم توفر قاعدة البيانات الأساسية وتوفر قاعدة بيانات بديلة. باستخدام واجهة برمجة التطبيقات، يمكنك بدء الانتقال التلقائي اليدوي في أي وقت
4. ابدأ الخوادم في الموقع الثانوي.
5. بمجرد انتهاء عملية الانتقال التلقائي، ويمكن الوصول إلى الموقع الأساسي السابق مرة أخرى، يجب تنفيذ المهام اليدوية التالية لإعداد النظام لاسترجاع مستقبلي.
   1. إيقاف عمليات Oracle WebLogic Server في الموقع الفاشل.
      إذا لم تقم بإيقافها أثناء تجاوز الفشل، فقد يتم تعليق العمليات. تأكد من إيقافها.
   2. بالنسبة إلى Oracle Autonomous Database Serverless، لا تحتاج إلى إعادة الحالة الأساسية الفاشلة يدويًا.
      بعد تجاوز فشل Oracle Autonomous Data Guard اليدوي، تتم إعادة توصيل قاعدة البيانات البديلة تلقائيًا أو إعادة تزويدها تلقائيًا (شفافية) عند عودة المنطقة إلى الإنترنت إذا لزم الأمر.
      راجع ملاحظات حول تجاوز الفشل اليدوي مع قاعدة بيانات بديلة للحصول على تفاصيل.
   3. بالنسبة إلى Oracle Autonomous Database on Dedicated Exadata Infrastructure، قم بإعادة قاعدة بيانات الحاوية الفاشلة إلى دور مُمكّن وبديل من صفحة التفاصيل الخاصة بها.
      بعد الانتقال التلقائي، يصبح دور قاعدة بيانات الحاوية الفرعية البديلة أساسيًا ويصبح دور قاعدة بيانات الحاوية الأساسية معطلاً في الحالة غير متاح.
      راجع الفشل في الانتقال إلى قاعدة البيانات البديلة في تكوين Autonomous Data Guard للحصول على التفاصيل.
   4. تحقق من التنفيذ الصحيح للنسخة المتماثلة للتكوين (من النسخة الأساسية الجديدة إلى النسخة البديلة الجديدة).