التحويل

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

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

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

بعد التحويل، تصبح الطوبولوجيا:

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

متى تستخدم التحويل

استخدم التحويل عندما:

• أنت تقوم بالصيانة على الأساسي الحالي.
• يكون الأساسي متدهورًا جزئيًا ولكن لا يزال بإمكانه الاستجابة للطلبات.
• تحتاج إلى RPO = 0 ولا يمكنك قبول فقدان البيانات.

لا تستخدم التحويل إذا كان الأساسي غير متوفر تمامًا. في هذه الحالة، استخدم تجاوز الفشل.

قبل البدء

تحقق مما يلي قبل البدء:

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

يضمن التبديل عدم فقدان البيانات، لكن وقت العملية يعتمد على كمية البيانات المتبقية التي يجب نسخها.

إنشاء الطوبولوجيا الجديدة

قم بإنشاء تكوين استبدال كامل حيث يصبح cluster-b هو المصدر و cluster-a هو الهدف.

# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels

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

switchover_config = {
    "clusters": [
        {
            "cluster_id": cluster_a_id,
            "connection_param": {
                "uri": cluster_a_addr,
                "token": cluster_a_token,
            },
            "pchannels": cluster_a_pchannels,
        },
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": cluster_b_id,
            "target_cluster_id": cluster_a_id,
        }
    ],
}

تطبيق الطوبولوجيا الجديدة

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

from pymilvus import MilvusClient

client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_a.update_replicate_configuration(**switchover_config)
    client_b.update_replicate_configuration(**switchover_config)
finally:
    client_a.close()
    client_b.close()

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

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

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

بعد أن يصبح cluster-b أساسيًا:

1. قم بتوجيه حركة مرور الكتابة إلى cluster-b.
2. تأكيد نجاح عمليات القراءة والكتابة على cluster-b.
3. تأكد من أن cluster-a لم يعد يتلقى كتابات التطبيق.
4. استمر في مراقبة النسخ المتماثل من cluster-b إلى cluster-a.

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

تحقق من أن cluster-b يعمل كأساسي جديد وأن البيانات لا تزال متسقة. تتضمن عمليات التحقق الشائعة ما يلي:

• مقارنة أعداد الصفوف للمجموعات المهمة.
• الاستعلام عن المفاتيح الأساسية المعروفة من كلا المجموعتين.
• قم بإجراء بحث تمثيلي على المفتاح الأساسي الجديد والاحتياطي القديم.
• قم بإجراء كتابة صغيرة على cluster-b وتأكد من نسخها إلى cluster-a.

التبديل مرة أخرى

للتبديل مرة أخرى في وقت لاحق، قم بتطبيق الطوبولوجيا الأصلية مرة أخرى:

cluster-a -> cluster-b

استخدم نفس تدفق التبديل. تأكد من إمكانية الوصول إلى الأساسي الحالي وأن النسخ المتماثل سليم قبل إعادة التبديل.

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

هل يفقد التحويل البيانات؟

لا. ينتظر التحويل حتى يتم نسخ البيانات المتبقية قبل أن يصبح الاحتياطي أساسيًا.

هل أحتاج إلى إيقاف كتابات التطبيق؟

يجب عليك إيقاف الكتابات مؤقتًا أو جعل الكتابات قابلة لإعادة المحاولة أثناء تغيير الدور. يتم رفض الكتابات المرسلة إلى الأساسي القديم بعد أن يتم إلغاء التبديل.

لماذا يستغرق التبديل وقتاً أطول من المتوقع؟

السبب الأكثر شيوعًا هو تأخر CDC. يجب أن يتلقى الأساسي الجديد البيانات المتبقية قبل أن يتمكن من تولي المسؤولية بأمان مع RPO = 0.

هل يمكنني إعادة محاولة طلب التحويل الفاشل؟

نعم. أعد المحاولة بنفس الطوبولوجيا المستهدفة.

ماذا يحدث للابتدائي القديم؟

يصبح الأساسي القديم في وضع الاستعداد. لا ينبغي أن يتلقى بعد ذلك عمليات كتابة التطبيق.