DR الخطة لقواعد البيانات
يمكنك استخدام Oracle GoldenGate وActive Data Guard وAutonomous Data Guard لتنفيذ DR لقواعد البيانات الموزعة في Oracle Cloud.
- يوفر Active Data Guard حماية شاملة للبيانات، وتوافرًا عاليًا، واستعادة البيانات بعد الكوارث لـ Oracle Database بطريقة بسيطة واقتصادية من خلال الحفاظ على نسخة متزامنة (استعدادية) مادية لقاعدة بيانات إنتاج في موقع بعيد. قاعدة البيانات البديلة مفتوحة للقراءة فقط أثناء نقل الإعادة ومراجعتها واستردادها.
على عكس طرق النسخ المتماثل للتخزين النموذجية، يقوم Active Data Guard بنسخ سجلات الإعادة المضمنة بالذاكرة فقط، والتحقق من النسخ المتماثل لمنع أي احتمال للفساد.
- Oracle GoldenGate هو منتج استنساخ منطقي متقدم يدعم النسخ المتماثل متعدد الأُسي، والنشر من مركز الوصل والتحدث، وتحويل البيانات. يوفر GoldenGate للعملاء خيارات مرنة للتعامل مع النطاق الكامل لمتطلبات النسخ المتماثل، بما في ذلك الأنظمة الأساسية للأجهزة غير المتجانسة.
- يوفر Autonomous Data Guard حماية البيانات واستعادتها بعد الكوارث لمثيلات قاعدة البيانات الذاتية في Oracle Cloud. عند تمكين Autonomous Data Guard لمثيل قاعدة بيانات مستقل، يتم إنشاء قاعدة بيانات بديلة في نفس المنطقة. في المناطق التي يوجد بها أكثر من نطاق إتاحة واحد، يتم توفير قاعدة البيانات البديلة في نطاق إتاحة مختلف عن نطاق قاعدة البيانات الأساسية. في المناطق ذات نطاق إتاحة واحد، يتم توفير قاعدة البيانات البديلة على جهاز فعلي مختلف عن قاعدة البيانات الأساسية. يراقب Autonomous Data Guard المثيل الأساسي، ويفشل تلقائيًا في الانتقال إلى قاعدة البيانات البديلة إذا أصبحت قاعدة البيانات الأساسية غير متاحة.
حول Oracle Maximum Availability Architecture
تستخدم كل طبقة من طبقات MAA التالية مجموعة مثالية من إمكانيات Oracle التي، عند نشرها معًا، تحقق مستويات الخدمة المستهدفة بشكل موثوق للانقطاعات المؤقتة غير المخطط لها وأحداث الصيانة المخططة:
- برونزي
توفر الطبقة البرونزية خدمة قاعدة البيانات الأساسية بأقل تكلفة ممكنة. يتم قبول مستوى منخفض من التوافر العالي وحماية البيانات مقابل تقليل تعقيد التكلفة والتنفيذ. قد تكون هذه البنية مناسبة لقواعد البيانات المستخدمة في الاختبار والتطوير وتطبيقات الإنتاج وقواعد البيانات الأقل أهمية.
تستخدم البنية إمكانات التوفر العالي المضمنة في Oracle Enterprise Edition. يتم تعيين قيمة برونزية افتراضيًا على بنية مثيل واحد أو تعدد المؤسسات في Oracle Database. يتم استخدام إمكانيات التوفر العالي لـ Oracle Restart أو Oracle Clusterware لإعادة بدء طبعة فاشلة أو خادم قاعدة بيانات أو أية خدمة مدارة ذات صلة. بالنسبة للتفسيرات المنطقية مثل الخطأ البشري، يمكنك استخدام عمليات الاسترجاع "لإرجاع" قاعدة البيانات إلى نقطة زمنية محددة. في سيناريو أسوأ الحالات الخاص بانقطاع مؤقت كامل للموقع، يلزم توفر وقت إضافي لاستعادة النظام وقاعدة البيانات واستعادتهما من عمليات النسخ الاحتياطي التي قد تؤدي إلى ساعات أو أيام تعطل.
يوصى دائمًا بإجراء نسخ احتياطي محلي داخل نفس مركز البيانات للحصول على أسرع استعادة. وتوصي Oracle أيضًا بالحفاظ على نسخة ثانية من النُسخ الاحتياطية في مركز بيانات بعيد للحماية من حالات انقطاع الموقع والكوارث. يمكنك استخدام Oracle Database Backup Cloud Service للحفاظ على نسخة احتياطية قائمة على السحابة لقواعد البيانات المحلية.
- Silver
تم تصميم الطبقة Silver لقواعد البيانات التي لا يمكنها انتظار إعادة التشغيل البارد أو الاستعادة من النسخ الاحتياطي، في حالة وجود مثيل قاعدة بيانات أو فشل في الخادم. قد تكون هذه البنية مناسبة لتطبيقات الإنتاج المهمة للأعمال وتحتاج إلى تقليل وقت التوقف عن العمل لحالات الفشل المحلية وأنشطة الصيانة المخطط لها الأكثر شيوعًا.
تم إنشاء البنية الفضية بناءً على أساس البنية البرونزية، كما تضيف Oracle Real Application Clusters (Oracle RAC) مجموعات نشطة للحد الأدنى أو الصفر من وقت التوقف في حالة فشل طبعة قاعدة البيانات أو الخادم، فضلاً عن عدم توقف قاعدة البيانات لأكثر أحداث الصيانة المخطط شيوعًا.
كما هو الحال في البنية البرونزية، يوفر Recovery Manager (RMAN) نسخًا احتياطية مُحسّنة لقاعدة البيانات لاستعادة التوفر في حالة وقوع انقطاع كامل للمجموعة أو كارثة.
- ذهب
تم تصميم الطبقة الذهبية لتلبية متطلبات مستوى الخدمة التي لا يمكنها تحمل فترات طويلة من التعطل وفقدان البيانات. توفر هذه المجموعة من أنماط البنية توفرًا عاليًا وحماية شاملة للبيانات لجميع أنواع حالات الانقطاع المؤقت غير المخطط لها، بما في ذلك عمليات تلف البيانات وحالات فشل قاعدة البيانات وحالات انقطاع الموقع. سوف تستفيد تطبيقات الإنتاج الحيوية للمهام التي تتطلب وقت استرداد سريعًا وصفرًا أو أقل فقد للبيانات لجميع انقطاعات قاعدة البيانات والنظام وأنشطة الصيانة المخطط لها من الإمكانات المضمنة في بنية مرجع الذهب.
توفر لك بنية مرجع الذهب، بناءً على بنية المرجع Silver، أربعة أنماط بنية باستخدام Oracle Active Data Guard. تختلف الأنماط من وضع الاستعداد النشط عن بُعد واحد مع الانتقال عقب الفشل للبداية السريعة ومراقب التوفر العالي، إلى تكوينات متعددة لقاعدة البيانات البديلة بما في ذلك تكتلات القارئ الاحتياطية، وأخيرًا المزامنة البعيدة (عبر المناطق) بدون تكوين بديل لخسارة البيانات.
- بلاتينيوم
يمكن أن توفر الطبقة البلاتينية وقت توقف عن العمل عند الانقطاع المؤقت وأنشطة الصيانة المخطط لها التي لا يمكن تحقيقها من خلال بنية الذهب. تعتمد البنية البلاتينية على البنية الذهبية من خلال إضافة نسخ Oracle GoldenGate للتخلص من وقت التوقف عن العمل في عمليات الترحيل وترقيات التطبيقات وترقيات قواعد البيانات. تتم حماية كل قاعدة بيانات من قواعد بيانات Oracle GoldenGate بواسطة قاعدة بيانات بديلة لتمكين عدم فقدان البيانات في حالة فشل قاعدة البيانات أو المجموعة أو الموقع.
على عكس بنيات MAA الأخرى، تكون اعتبارات التطبيق مطلوبة لدمج Oracle GoldenGate في البنية، لضمان تنفيذ اكتشاف التعارض وحلها بشكل صحيح. قد تكون خدمات البيانات العالمية أو إدارة خدمة التطبيقات المخصصة مطلوبة أيضًا لتحقيق وقت توقف للتطبيقات الصفرية للأنشطة مثل الترحيل وترقيات قاعدة البيانات.
استخدام حارس البيانات النشط
مزايا Active Data Guard
يوفر Active Data Guard العديد من المزايا.
- تأمين النسخ المماثل المادي.
قاعدة البيانات البديلة مفتوحة للقراءة فقط حتى يتم ضمان اتساق البيانات.
لاحظ أنه بدءًا من Oracle Database 19c، يمكنك إصدار تحديث عرضي وإدراج تعليمات إلى قاعدة البيانات البديلة، والتي تعيد توجيه الإرشادات إلى قاعدة البيانات الأساسية.
- نسخ بسيط وسريع أحادي الاتجاه من Oracle Database كامل.
يتعامل التكوين الافتراضي مع معظم أحمال العمل حتى تكون هناك تكلفة إضافية إدارية ضئيلة.
- لا قيود.
يدعم تطبيق Oracle Data Guard Redo جميع ميزات Oracle ويقوم بنسخ جميع أنواع البيانات والتخزين وحزم PL/SQL وDDL بشفافية دون اعتبارات خاصة.
- أفضل حماية للبيانات.
يؤدي النسخ المتماثل مباشرة من الذاكرة إلى عزل قاعدة البيانات البديلة عن تلف المدخلات/المخرجات الذي يمكن أن يحدث في قاعدة البيانات الأساسية. اكتشاف التلف الضائع الصامت-الكتابة والذي يمكن أن يحدث بشكل مستقل في قاعدة البيانات الأساسية أو البديلة. الكشف عن تلف الكتل المادية وإصلاحه تلقائيًا والذي يمكن أن يحدث بشكل مستقل في قاعدة البيانات الأساسية أو البديلة.
- اختيار التزامن مع عدم فقدان البيانات أو عدم تزامن ذلك مع حماية شبه الصفر لفقدان البيانات.
- تحسين RoI.
يمكنك إلغاء تحميل أحمال عمل للقراءة فقط مثل تطبيقات إعداد التقارير والاستعلامات المخصصة وعمليات استخراج البيانات إلى قاعدة بيانات فعلية متزامنة.
- يقوم أمر واحد بتحويل قاعدة البيانات البديلة الفعلية كقراءة/كتابة مفتوحة لنظام الاختبار. يقوم الأمر الثاني بتحويله مرة أخرى إلى قاعدة بيانات فعلية بديلة وإعادة مزامنته مع قاعدة البيانات الأساسية. البيانات الأساسية محمية دائمًا.
- إدارة متكاملة لتكوين كامل باستخدام سطر أوامر Oracle Data Guard Broker وتجاوز فشل قاعدة البيانات تلقائيًا.
- مدعوم لقاعدة بيانات عقدة واحدة أو تكوين قاعدة بيانات متعددة العقد (Real Application Cluster).
- استمرارية التطبيق، لحماية معاملاتك أثناء التنقل.
يقوم Active Data Guard بإخفاء حالات انقطاع قاعدة البيانات عن المستخدمين والتطبيقات عن طريق استعادة العمل أثناء التنقل لجلسات قاعدة البيانات المتأثرة.
أوضاع التكوين
- الحماية القصوىيوفر وضع الحماية هذا فقدانًا للبيانات إذا فشلت قاعدة البيانات الأساسية. لضمان عدم إمكانية حدوث فقد للبيانات، يتم إيقاف تشغيل قاعدة البيانات الأساسية إذا كان الخطأ يمنعها من كتابة تدفق الإعادة إلى سجل الإعادة البديلة لقاعدة بيانات بديلة واحدة على الأقل.
ملاحظة:
هذا الوضع غير متوفر لقواعد البيانات الذاتية. بالنسبة لخدمة Exadata Cloud Service وExadata Cloud@Customer، يمكنك تكوين هذا الوضع يدويًا، ولكن مستوى التحكم في السحابة لن يعكسه. - الحد الأقصى للتوفر
يوفر وضع الحماية هذا أعلى مستوى ممكن من حماية البيانات دون المساس بتوافر قاعدة البيانات الأساسية. مثل وضع "الحد الأقصى للحماية"، لا يتم تثبيت المعاملة إلا بعد كتابة الإعادة اللازمة لاسترداد هذه المعاملة في سجل الإعادة المحلي عبر الإنترنت وإلى سجل الإعادة البديلة لقاعدة بيانات احتياطية واحدة على الأقل متسقة مع المعاملات. على عكس وضع "الحد الأقصى للحماية"، لا يتم إيقاف تشغيل قاعدة البيانات الأساسية إذا كان الخطأ يمنعها من كتابة تدفق الإعادة إلى سجل الإعادة البديل البعيد. بدلاً من ذلك، يتم خفض مستوى قاعدة البيانات الأساسية وتكوين Data Guard إلى الحالة
UNSYNCHRONIZED. عند توفر بديل واحد على الأقل، تتم إعادة مزامنة قاعدة البيانات البديلة تلقائيًا. - الحد الأقصى للأداء
يوفر وضع الحماية هذا (الافتراضي) أعلى مستوى ممكن من حماية البيانات دون التأثير على أداء قاعدة البيانات الأساسية. ويتم ذلك من خلال السماح للمعاملة بالالتزام عند كتابة بيانات الإعادة اللازمة لاسترداد هذه المعاملة بشكل غير متزامن في سجل الإعادة المحلي المباشر. عند استخدام ارتباطات الشبكة ذات النطاق الترددي الكافي، يوفر هذا الوضع مستوى من حماية البيانات يقترب من وضع الحد الأقصى للتوفر مع الحد الأدنى من التأثير على أداء قاعدة البيانات الأساسية.
اعتبارات تعيين قاعدة البيانات
لتحسين التوافر واستعادة البيانات بعد الكوارث، ضع نظام قاعدة البيانات لقاعدة البيانات البديلة في نطاق إتاحة مختلف عن نظام قاعدة البيانات لقاعدة البيانات الأساسية.
إذا قمت بتمكين Data Guard لقاعدة بيانات وكانت قاعدة البيانات البديلة في نفس نطاق التوفر مثل المجال الأساسي (إما حسب الاختيار أو لأن المنطقة بها نطاق إتاحة واحد)، فقم بوضع قاعدة البيانات البديلة في نطاق خطأ مختلف عن نطاق قاعدة البيانات الأساسية.
إذا كانت قواعد البيانات الأساسية والمتوافقة هي عبارة عن نظامين من أنظمة RAC الافتراضية لجهاز RAC وكلاهما في نفس نطاق التوفر، فإننا نوصي بتوزيع جميع العقد الأربعة (اثنان للعقد الأساسي واثنان للوقوف الاحتياطي) عبر جميع نطاقات الأخطاء الثلاثة في نطاق التوفر. يضمن هذا التكوين أعلى توفر ممكن، مع الاستفادة من جميع نطاقات الأخطاء الثلاثة. في هذا السيناريو، يمكن أن توجد نقطة توصيل واحدة فقط من عقدتي قاعدة البيانات البديلة في نطاق خطأ لا يتضمن أية نقاط توصيل أخرى من قاعدة البيانات الأساسية أو البديلة.
لضمان الانتقال الأمثل للأدوار بين قاعدة البيانات الأساسية والاستعداد، توصي Oracle بتقليص حجم وتكوين قاعدتي البيانات بشكل متماثل.
أفضل ممارسات التكوين
راجع "أفضل ممارسات Oracle Data Guard" في نظرة عامة على التوافر العالي من Oracle Database وأفضل الممارسات.
استخدام Oracle GoldenGate
- متطلبات النسخ المتماثل المتقدمة، مثل النسخ المتماثل متعدد المستويات ثنائي الاتجاه، والنسخ المتماثل من مجموعة فرعية، والنسخ المتماثل متعدد إلى واحد، والنسخ المتقاطع، وتحويلات البيانات
- الصيانة وعمليات الترحيل التي تتطلب عدم توقف عن العمل باستخدام النسخ المتماثل ثنائي الاتجاه
- ترحيل بين الأنظمة الأساسية غير مدعوم بواسطة Data Guard (على سبيل المثال، ترحيل الأنظمة الأساسية المتقاطعة)
- دعم الأنظمة الموزعة لنسخة قاعدة بيانات متعددة (على سبيل المثال، النسخة 1 في 12.2 والنسخة 2 في 19c)
- دعم الأنظمة الأساسية لقاعدة البيانات المتعددة (على سبيل المثال، النسخة المتماثلة 1 موجودة على Oracle والنسخة 2 على قاعدة بيانات غير Oracle DB)
أوضاع التكوين
استخدم بنية الخدمات الصغيرة Oracle GoldenGate، التي توفر نظامًا أساسيًا آمنًا وشاملًا وقابلاً للتطوير للنسخ المتماثل في السحابة. لتقليل التكلفة الإضافية غير المباشرة على خوادم قاعدة البيانات، توصي Oracle بتوزيع GoldenGate في تكوين لوحة الوصل.
يدعم GoldenGate العديد من الهياكل، كما هو موضح في المخطط التالي. اختر وضع يناسب حالة الاستخدام.
أفضل ممارسات التكوين
نظرًا لقيام Oracle GoldenGate بنسخ البيانات على مستوى العمليات، فإننا نوصي بتنفيذ اكتشاف التعارض وحلها (CDR) لاتساق البيانات بين موقعين. يتم تحديد التعارضات على الفور والتعامل معها بسكريبتات آلية.
إذا كنت تستخدم GoldenGate في المقام الأول لأغراض إجراءات مواجهة الكوارث وكانت عملية النسخ المماثل أحادية الاتجاه، فإننا نوصي بإضافة Data Guard بين منطقتين. إن القيام بذلك يوفر حلاً خالٍ من البيانات مع اتساق قوي للبيانات بين المثيل الأساسي ومثيل Data Guard. كما يخفف هذا التكوين من المصروفات الإضافية لتشغيل استخراج GoldenGate من قاعدة البيانات الأساسية.
وصف الشكل التوضيحي db-dg-gg.png
ملاحظة:
تعرض البنية نطاقات إتاحة متعددة (ADs). بالنسبة للمنطقة التي تحتوي على AD واحد، قم بضبط البنية لتوزيع الموارد الخاصة بك عبر نطاقات الأخطاء داخل AD.
قم بنشر Oracle GoldenGate أيضًا في تكوين التوفر العالي. يمكنك استخدام النسخ المتماثل لنظام ملفات Oracle ASM Cluster File System (ACFS) لملفات GoldenGate المهمة.
استخدم Active Data Guard وGoldenGate
Oracle GoldenGate وActive Data Guard لا يستبعد أحدهما الآخر. يمكنك استخدامها معًا لتحقيق هدف نقطة الاسترداد (RPO) بالقيمة صفر (أي، عدم وجود خطر فقدان البيانات)، لأن GoldenGate غير متزامن بطبيعته بينما يمكن لـ Active Data Guard توفير نسخ متزامن إلى جانب الميزات الرئيسية الأخرى مثل التحقق من كتلة البيانات وإصلاح الكتل تلقائيًا واستمرارية التطبيق.
- استخدم Active Data Guard الاحتياطي لحماية البيانات بعد الكوارث والترقيات المتعاقبة لقاعدة بيانات OLTP بالغة الأهمية. استخدم GoldenGate لاستخراج البيانات من قاعدة البيانات الأساسية Data Guard (أو من قاعدة البيانات البديلة باستخدام وضع GoldenGate ALO) لتحديث ETL لمستودع بيانات المؤسسة.
- استخدم استنساخ المجموعة الفرعية GoldenGate لاستخراج البيانات وتحويلها وتجميعها من مصادر بيانات متعددة إلى مخزن بيانات تشغيل مركزي (ODS). يدعم ODS أنظمة التطبيق الحيوية للمهام التي تحقق إيرادات كبيرة للشركة. استخدم قاعدة بيانات احتياطية Active Data Guard لحماية ODS، مما يوفر حماية مثالية للبيانات وتوفرها.
- استخدم النسخ المتماثل متعدد الرؤساء GoldenGate لمزامنة عدة قواعد بيانات، كل منها موجود في مناطق جغرافية مختلفة. تحتوي كل نسخة من GoldenGate على قاعدة بيانات احتياطية محلية متزامنة خاصة بـ Data Guard تتيح إمكانية الانتقال عقب الفشل دون بيانات في حالة حدوث انقطاع مؤقت.
ملاحظة:
لتنفيذ بنية الحد الأقصى للإتاحة على مستوى البلاتين، استخدم Oracle Real Application Clusters (Oracle RAC) وActive Data Guard، بالإضافة إلى Oracle GoldenGate.