تجاوز الفشل

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

يفترض هذا الدليل أن الطوبولوجيا الأصلية:

cluster-a (primary)  ->  cluster-b (standby)

بعد تجاوز الفشل، يصبح cluster-b أساسيًا مستقلاً بعد تجاوز الفشل، يصبح أساسيًا مستقلًا:

cluster-b (primary)

متى يتم استخدام تجاوز الفشل

استخدم تجاوز الفشل فقط عندما:

• يتعذر على الأساسي الأصلي الاستجابة للطلبات.
• لا يمكن استرداد الأساسي في غضون وقت مقبول.
• استعادة توافر الكتابة أكثر أهمية من انتظار الأساسي القديم.

إذا كان الأساسي لا يزال يمكن الوصول إليه، استخدم التحويل بدلاً من ذلك. يتجنب التحويل فقدان البيانات.

مخاطر فقدان البيانات

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

يتم تحديد الفقدان المحتمل للبيانات من خلال تأخر CDC في الوقت الذي أصبح فيه الأساسي غير متوفر.

قبل تشغيل تجاوز الفشل، يجب فهم المفاضلة:

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

قبل أن تبدأ

قم بتأكيد ما يلي:

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

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

بناء تكوين تجاوز الفشل

قم ببناء تكوين يحتوي فقط على الكتلة الاحتياطية ولا يحتوي على طوبولوجيا النسخ المتماثل. تعيين force_promote=True.

# If you followed Set Up CDC Replication, cluster B is the original target cluster.
cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

failover_config = {
    "clusters": [
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        }
    ],
    "cross_cluster_topology": [],
    "force_promote": True,
}

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

أرسل الطلب إلى المجموعة الاحتياطية.

from pymilvus import MilvusClient

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.update_replicate_configuration(**failover_config)
finally:
    client_b.close()

إذا نجح الطلب، يصبح cluster-b أساسيًا مستقلاً ويمكنه قبول الكتابات.

إعادة توجيه حركة مرور التطبيق

بعد الترقية:

1. إعادة توجيه حركة مرور الكتابة إلى cluster-b.
2. قم بإزالة cluster-a من نقاط نهاية الكتابة وموازنات التحميل وسجلات DNS والأتمتة.
3. تحقق من أن cluster-b يقبل الكتابة.
4. حافظ على cluster-a معزولاً حتى يتم إيقاف تشغيله أو إعادة بنائه بشكل صريح.

مثال للتحقق من الكتابة:

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.insert(
        collection_name="test_collection",
        data=[{"id": 1, "vector": [0.1] * 128}],
    )
finally:
    client_b.close()

اضبط اسم المجموعة وحقول المخطط لتتناسب مع النشر الخاص بك.

التحقق من النتيجة

تحقق من المجموعة التي تمت ترقيتها مباشرة:

• تنجح عمليات الكتابة على cluster-b.
• تُرجع عمليات القراءة البيانات المتوقعة.
• لا يكتب أي مكون تطبيق إلى cluster-a.

التعامل مع الأساسي القديم

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

لا تقم بإعادة الاتصال cluster-a بالطوبولوجيا القديمة تلقائيًا. إعادة تقديم الأساسي القديم هي مهمة استرداد منفصلة يجب التخطيط لها بعناية.

التقليل من فقدان البيانات

لا يمكنك إزالة جميع مخاطر فقدان البيانات من تجاوز الفشل، ولكن يمكنك تقليلها:

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

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

هل يؤدي تجاوز الفشل دائمًا إلى فقدان البيانات؟

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

كم من الوقت يستغرق تجاوز الفشل؟

عادةً ما يكتمل في غضون ثوانٍ، اعتمادًا على حالة المجموعة وتوافر مستوى التحكم في الطائرة الاحتياطية.

هل يمكنني تشغيل تجاوز الفشل على الأساسي؟

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

هل يمكن إعادة انضمام الأساسي القديم تلقائياً؟

لا. بعد تجاوز الفشل، يجب التعامل مع الأساسي القديم على أنه قديم وإيقاف تشغيله أو إعادة بنائه قبل أن يتمكن من المشاركة في النسخ المتماثل مرة أخرى.

كيف يمكنني تجنب انقسام الدماغ؟

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