إعادة الإصدار 4.53.01 من Apigee Edge

إذا حدث خطأ أثناء تحديث Edge إلى الإصدار 4.53.01، يمكنك التراجع عن التغييرات التي أجريتها على المكوّن الذي تسبّب في حدوث الخطأ ثم إعادة محاولة التحديث.

يمكنك الرجوع إلى أي من إصدارات الإصدارات الرئيسية التالية من Edge 4.53.01:

  • الإصدار 4.53.00
  • الإصدار 4.52.02

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

العودة إلى الإصدار اعتبارات خاصة بالبرامج
4.53.00 Zookeeper وPostgres وLDAP
4.52.02 Zookeeper وCassandra وPostgres وLDAP

في ما يلي السيناريو الذي قد تحتاج فيه إلى تنفيذ عملية التراجع:

العودة إلى إصدار رئيسي أو ثانوي سابق على سبيل المثال، من 4.53.01 إلى 4.53.00.

لمزيد من المعلومات، يُرجى الاطّلاع على عملية إصدار Apigee Edge.

ترتيب العودة إلى الحالة السابقة

يجب إعادة إصدار المكوّنات إلى الإصدار السابق بالترتيب العكسي لترتيب ترقيتها، باستثناء خوادم الإدارة التي يجب إعادة إصدارها إلى الإصدار السابق بعد Cassandra. سيبدو الترتيب العام النموذجي لعملية الرجوع إلى الإصدار السابق من Private Cloud 4.53.01 على النحو التالي:

  1. إرجاع Qpid والمكوّنات الأخرى ذات الصلة بالإحصاءات وPostgres إلى الإصدار السابق
  2. إعادة أجهزة التوجيه ومعالجات الرسائل إلى الحالة السابقة
  3. العودة إلى الإصدار السابق من Cassandra وZookeeper
  4. خادم إدارة العودة إلى الإصدار السابق
  5. العودة إلى إعدادات LDAP السابقة

على سبيل المثال، لنفترض أنّك قد رقّيت مجموعة Cassandra بأكملها وجميع خوادم الإدارة وبعض RMP إلى الإصدار 4.53.01 من الإصدار 4.52.02 وأردت التراجع. في هذه الحالة، عليك إجراء ما يلي:

  • التراجع عن جميع RMP واحدًا تلو الآخر
  • إرجاع مجموعة Cassandra بأكملها إلى حالتها السابقة باستخدام النسخ الاحتياطية
  • التراجع عن تغييرات عقد خادم Edge Management واحدة تلو الأخرى

مَن يمكنه إجراء عملية التراجع؟

يجب أن يكون المستخدم الذي يجري عملية الرجوع إلى إصدار سابق هو المستخدم نفسه الذي حدَّث Edge في الأصل، أو مستخدم لديه امتيازات الجذر.

بشكلٍ تلقائي، يتم تشغيل مكوّنات Edge بصفتها المستخدم "apigee". في بعض الحالات، قد يتم تشغيل مكوّنات Edge كمستخدمين مختلفين. على سبيل المثال، إذا كان على جهاز التوجيه الوصول إلى منافذ مميّزة، مثل المنافذ التي تقل عن 1000، عليك تشغيل جهاز التوجيه كجذر أو كمستخدم لديه إذن الوصول إلى هذه المنافذ. أو يمكنك تشغيل أحد المكوّنات كمستخدم واحد، وتشغيل مكوّن آخر كمستخدم آخر.

المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا

تتشارك مكوّنات Edge التالية في الرمز البرمجي الشائع. لذلك، لإرجاع أي من هذه المكوّنات إلى الإصدار السابق على إحدى العُقد، يجب إرجاع جميع هذه المكوّنات الموجودة على تلك العقدة.

  • edge-management-server (خادم الإدارة)
  • edge-message-processor (معالج الرسائل)
  • edge-router (جهاز التوجيه)
  • edge-postgres-server (خادم Postgres)
  • edge-qpid-server (خادم Qpid)

على سبيل المثال، إذا كان لديك "خادم الإدارة" و"الموجّه" و"معالج الرسائل" مثبّتة على العقدة، عليك التراجع عن تثبيت الثلاثة معًا للتراجع عن تثبيت أيّ منها.

العودة إلى الإصدار السابق من Cassandra

عند إجراء ترقية رئيسية لـ Cassandra على عقدة معيّنة، تعدّل Cassandra مخطط البيانات المخزّنة على تلك العقدة. نتيجةً لذلك، لا يمكن إجراء عملية رجوع مباشرة في مكانها.

سيناريوهات العودة إلى الحالة السابقة

يتوافق الإصدار Cassandra 4.0.X، المتاح مع Edge for Private Cloud 4.53.01، مع المكوّنات الأخرى من Private Cloud 4.52.02.

يُرجى الرجوع إلى الجدول أدناه للاطّلاع على ملخّص لاستراتيجيات التراجع المختلفة التي يمكنك استخدامها:

السيناريو استراتيجية العودة إلى الإصدار السابق
مركز بيانات واحد، تمت ترقية بعض عُقد Cassandra استخدام النُسخ الاحتياطية
Single DC, all Cassandra nodes upgraded لا تعُد إلى الإصدار السابق من Cassandra. يمكن التراجع عن التغييرات التي تم إجراؤها على المكوّنات الأخرى.
مركز بيانات واحد، تمت ترقية جميع العُقد (Cassandra وغيرها) لا تعُد إلى الإصدار السابق من Cassandra. يمكن التراجع عن التغييرات التي تم إجراؤها على المكوّنات الأخرى.
وحدات تحكّم متعددة في مركز بيانات واحد، وتمت ترقية بعض العُقد في وحدة تحكّم واحدة إعادة الإنشاء من شهادة رقمية حالية
مراكز بيانات متعددة، تمت ترقية جميع عُقد Cassandra في بعض مراكز البيانات إعادة الإنشاء من شهادة رقمية حالية
عُقد متعددة في مركز البيانات (DC) وCassandra لآخر مركز بيانات تمت ترقيته حاوِل إكمال عملية الترقية. إذا لم يكن ذلك ممكنًا، يمكنك التراجع عن التغييرات في مركز بيانات واحد باستخدام نسخة احتياطية. إعادة إنشاء الشهادات الرقمية المتبقية من الشهادة الرقمية التي تم التراجع عنها
مراكز بيانات متعددة، تمت ترقية جميع عُقد Cassandra لا تعُد إلى الإصدار السابق من Cassandra. يمكن التراجع عن التغييرات التي تم إجراؤها على المكوّنات الأخرى.
تعدُّد مراكز البيانات، وترقية جميع العُقد (Cassandra وغيرها) لا تعُد إلى الإصدار السابق من Cassandra. يمكن التراجع عن التغييرات التي تم إجراؤها على المكوّنات الأخرى.

اعتبارات عامة

عند التفكير في التراجع عن التغييرات، يُرجى مراعاة ما يلي:

  • التراجع عن إصدار وقت التشغيل أو مكونات الإدارة: إذا كنت تريد التراجع عن إصدار مكونات مثل edge-management-server أو edge-message-processor أو أي مكون غير Cassandra إلى الإصدار 4.52.02 من Private Cloud، ننصحك بعدم التراجع عن إصدار Cassandra. يتوافق إصدار Cassandra الذي تم شحنه مع Private Cloud 4.53.00 مع جميع مكوّنات Edge for Private Cloud 4.52.02 غير Cassandra. يمكنك التراجع عن تغييرات المكوّنات غير التابعة لـ Cassandra باستخدام المنهجية الواردة هنا، مع إبقاء Cassandra على الإصدار 4.0.13.
  • الرجوع إلى الإصدار السابق بعد ترقية مجموعة Cassandra بالكامل إلى الإصدار 4.0.X: إذا تمت ترقية مجموعة Cassandra بالكامل إلى الإصدار 4.0.X كجزء من الترقية إلى الإصدار 4.53.00 من Private Cloud، يُنصح بمواصلة إعداد هذه المجموعة وعدم الرجوع إلى الإصدار السابق من Cassandra. تتوافق المكوّنات، مثل edge-management-server وedge-message-processor وedge-router وما إلى ذلك، من الإصدار 4.52.02 من Private Cloud مع الإصدار 4.0.X من Cassandra.
  • التراجع عن ترقية Cassandra: إذا واجهت مشاكل أثناء ترقية Cassandra، يمكنك التراجع عن الترقية. يمكن اتّباع استراتيجيات التراجع المدرَجة في هذه المقالة استنادًا إلى الحالة التي تكون فيها أثناء عملية الترقية.
  • العودة إلى الحالة السابقة باستخدام النُسخ الاحتياطية: لا تتوافق النُسخ الاحتياطية التي تم إنشاؤها من Cassandra 4.0.X مع النُسخ الاحتياطية من Cassandra 3.11.X. لإرجاع Cassandra باستخدام استعادة النسخة الاحتياطية، يجب أخذ نُسخ احتياطية من Cassandra 3.11.X قبل محاولة الترقية.

العودة إلى الإصدار السابق من Cassandra باستخدام إعادة الإنشاء

المتطلبات الأساسية

  • أنت تشغّل مجموعة Edge for Private Cloud 4.52.02 على مستوى مراكز بيانات متعددة.
  • أنت بصدد ترقية Cassandra من الإصدار 3.11.X إلى الإصدار 4.0.X وواجهت مشاكل أثناء الترقية.
  • لديك مركز بيانات واحد على الأقل يعمل بكامل طاقته في المجموعة ولا يزال يستخدِم الإصدار القديم من Cassandra (الإصدار 3.11.X).

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

الخطوات العامة

  1. اختَر مركز بيانات واحدًا (تمت ترقيته جزئيًا أو كليًا) تريد التراجع عنه. توجيه زيارات وقت التشغيل إلى مركز بيانات آخر يعمل
  2. حدِّد عقدة البداية في مركز البيانات وابدأ بإحدى عقد البداية.
  3. أوقِف عقدة Cassandra وألغِ تثبيتها ونظِّفها.
  4. ثبِّت الإصدار الأقدم من Cassandra على العُقدة واضبطه حسب الحاجة.
  5. أزِل الإعدادات الإضافية التي تمت إضافتها سابقًا.
  6. كرِّر الخطوات المذكورة أعلاه لجميع العُقد الأولية في مركز البيانات، واحدة تلو الأخرى.
  7. كرِّر الخطوات أعلاه لجميع عُقد Cassandra المتبقية في مركز البيانات، واحدة تلو الأخرى.
  8. إعادة إنشاء العُقد من مركز البيانات الوظيفي الحالي، واحدة تلو الأخرى
  9. أعِد تشغيل جميع مكونات edge-* في مركز البيانات المرتبطة بـ Cassandra.
  10. اختبِر حركة المرور وأعِد توجيهها إلى مركز البيانات هذا.
  11. كرِّر الخطوات لكل مركز بيانات، واحدًا تلو الآخر.

الخطوات التفصيلية

  1. اختَر مركز بيانات واحدًا تتم فيه ترقية بعض أو كل عُقد Cassandra. توجيه كل زيارات وكيل وقت التشغيل وزيارات الإدارة من مركز البيانات هذا أثناء التراجع عن تغييرات عقد Cassandra في مركز البيانات هذا تأكَّد من أنّ جميع عُقد Cassandra في حالة UN (نشطة/عادية) عند تنفيذ الأمر nodetool ring على العُقد. إذا كانت بعض العُقد متوقّفة، عليك تحديد المشكلة وحلّها وإعادة تشغيل هذه العُقد قبل المتابعة.

    اطّلِع على المثال الوارد في ما يلي:

    /opt/apigee/apigee-cassandra/bin/nodetool status
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
    UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
    UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
    UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
    UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    يمكنك تنفيذ nodetool describecluster على العُقد لفهم الحالة الحالية للمجموعة بأكملها. على سبيل المثال، يعرض ما يلي مثيلاً لمجموعة من مركزَي بيانات حيث تعمل جميع عُقد DC-1 بالإصدار 4 من Cassandra، بينما تعمل جميع عُقد DC-2 بالإصدار 3 من Cassandra:

    # On nodes where Cassandra is upgraded
    /opt/apigee/apigee-cassandra/bin/nodetool describecluster
    Cluster Information:
        Name: Apigee
        Snitch: org.apache.cassandra.locator.PropertyFileSnitch
        DynamicEndPointSnitch: enabled
        Partitioner: org.apache.cassandra.dht.RandomPartitioner
        Schema versions:
            2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
            129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
    
    Stats for all nodes:
        Live: 6
        Joining: 0
        Moving: 0
        Leaving: 0
        Unreachable: 0
    
    Data Centers:
        dc-1 #Nodes: 3 #Down: 0
        dc-2 #Nodes: 3 #Down: 0
    
    Database versions:
        4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
        3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]
    
    Keyspaces:
        system_schema -> Replication class: LocalStrategy {}
        system -> Replication class: LocalStrategy {}
        auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
        system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
        system_traces -> Replication class: SimpleStrategy {replication_factor=2}
        system_auth -> Replication class: SimpleStrategy {replication_factor=1}
    
    # On nodes where Cassandra is not upgraded
    /opt/apigee/apigee-cassandra/bin/nodetool describecluster
    Cluster Information:
        Name: Apigee
        Snitch: org.apache.cassandra.locator.PropertyFileSnitch
        DynamicEndPointSnitch: enabled
        Partitioner: org.apache.cassandra.dht.RandomPartitioner
        Schema versions:
            2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
            129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
            
  2. تحديد العُقد الأولية في مركز البيانات: يُرجى الرجوع إلى القسم كيفية تحديد العُقد الأولية في الملحق. نفِّذ الخطوات أدناه على إحدى عُقد البداية:
  3. إيقاف وإلغاء تثبيت البيانات وتنظيفها من عقدة Cassandra اختَر أول عقدة أساسية في الإصدار 4 من Cassandra في مركز البيانات هذا. توقّف عن ذلك.
    # Stop Cassandra service on the node
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
    
    # Uninstall Cassandra software
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
    
    # Wipe out Cassandra data
    rm -rf /opt/apigee/data/apigee-cassandra
            
  4. ثبِّت برنامج Cassandra القديم على العُقدة واضبط بعض الإعدادات. نفِّذ ملف bootstrap الخاص بالإصدار 4.52.02 من Edge for Private Cloud.
  5. # Download bootstrap of 4.52.02
    curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord
    
    # Execute bootstrap of 4.52.02
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
        
  6. أنشئ الملف /opt/apigee/customer/application/cassandra.properties أو عدِّله.
  7. أضِف المحتوى التالي إلى الملف. ipOfNode هو عنوان IP للعقدة التي تستخدمها Cassandra للتواصل مع عُقد Cassandra الأخرى:
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  8. تأكَّد من أنّ مستخدم Apigee يملك الملف ويمكنه قراءته:
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  9. ثبِّت Cassandra وأعِدّها على النحو التالي:
  10. # Install cassandra version 3.11.X
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
    # Setup cassandra while passing standard configuration file
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
    # Ensure Cassandra version is correct and service is running
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  11. تأكَّد من بدء تشغيل العُقدة. تحقَّق من الأمر التالي على هذه العُقدة والعُقد الأخرى في المجموعة. يجب أن تشير العقدة إلى أنّها في الحالة "UN" (نشطة/عادية):
    /opt/apigee/apigee-cassandra/bin/nodetool status
  12. أزِل الإعدادات الإضافية التي أضفتها سابقًا من الملف /opt/apigee/customer/application/cassandra.properties.
  13. كرِّر الخطوات من 3 إلى 10 على جميع عقد البذور في Cassandra في مركز البيانات، واحدة تلو الأخرى.
  14. كرِّر الخطوات من 3 إلى 10 على جميع عُقد Cassandra المتبقية في مركز البيانات، واحدة تلو الأخرى.
  15. أعِد إنشاء جميع العُقد في مركز البيانات من مركز بيانات يعمل بإصدار Cassandra الأقدم. نفِّذ هذه الخطوة على عقدة واحدة في كل مرة:
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    قد يستغرق هذا الإجراء بعض الوقت. يمكنك تعديل streamingthroughput إذا لزم الأمر. اطّلِع على nodetool netstats لمعرفة حالة اكتمال العملية.

  16. (اختياري) نفِّذ أمر الإصلاح في عقدة Cassandra إذا لم تتم إعادة إنشاء البيانات.
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  17. أعِد تشغيل جميع مكوّنات edge-* في مركز البيانات، واحدًا تلو الآخر:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. التحقّق من صحة مركز البيانات هذا وإعادة توجيه الزيارات إليه إجراء بعض عمليات التحقّق من صحة بيانات الزيارات في وقت التشغيل وواجهات برمجة التطبيقات الإدارية في مركز البيانات هذا، وبدء إعادة توجيه الزيارات إلى الخادم الوكيل وواجهة برمجة التطبيقات الإدارية إليه
  19. كرِّر الخطوات أعلاه لكل مركز بيانات تريد التراجع عنه.

العودة إلى الإصدار السابق من Cassandra باستخدام نسخة احتياطية

المتطلبات الأساسية

  1. أنت بصدد ترقية Cassandra من الإصدار 3.11.X إلى الإصدار 4.0.X وواجهت مشاكل أثناء الترقية.
  2. يجب أن تتوفّر لديك نُسخ احتياطية للعُقدة التي تريد العودة إلى إصدارها السابق. تم إنشاء النسخة الاحتياطية قبل محاولة الترقية من الإصدار 3.11.X إلى الإصدار 4.0.X.

الخطوات

  1. اختَر عقدة واحدة تريد التراجع عنها. إذا كنت بصدد إرجاع جميع العُقد في مركز بيانات باستخدام نُسخ احتياطية، ابدأ بعُقد البداية أولاً. راجِع القسم "كيفية تحديد العُقد الأولية" في الملحق.

  2. أوقِف عقدة Cassandra وألغِ تثبيتها ونظِّفها باتّباع الخطوات التالية:

    # Stop Cassandra service on the node
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
    
    # Uninstall Cassandra software
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
    
    # Wipe Cassandra data
    rm -rf /opt/apigee/data/apigee-cassandra
  3. ثبِّت برنامج Cassandra القديم على العقدة واضبطه:

    • نفِّذ ملف bootstrap لإصدار Edge for Private Cloud 4.52.02:
    • # Download bootstrap for 4.52.02
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord
      
      # Execute bootstrap for 4.52.02
      sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • أنشئ الملف /opt/apigee/customer/application/cassandra.properties أو عدِّله:
    • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • تأكَّد من أنّ ملف المفتاح يملكه مستخدم Apigee ويمكن قراءته:
    • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • ثبِّت Cassandra وأعِدّها على النحو التالي:
    • # Install Cassandra version 3.11.X
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
      
      # Set up Cassandra with the standard configuration file
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
      
      # Verify Cassandra version and check service status
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    تأكَّد من بدء تشغيل العُقدة. تحقَّق من الأمر التالي على هذه العُقدة والعُقد الأخرى في المجموعة. يجب أن تشير العُقد إلى أنّ هذه العقدة في الحالة "UN":

    /opt/apigee/apigee-cassandra/bin/nodetool status
  4. أوقِف خدمة Cassandra واستعِد النسخة الاحتياطية. يُرجى الرجوع إلى مستندات الاحتفاظ بنسخة احتياطية من البيانات واستعادتها للحصول على مزيد من التفاصيل:

    # Stop Cassandra service on the node
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
    
    # Wipe the data directory in preparation for restore
    rm -rf /opt/apigee/data/apigee-cassandra/data
    
    # Restore the backup taken before the upgrade attempt
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile
            
  5. بعد استعادة النسخة الاحتياطية، أزِل الإعدادات الإضافية باتّباع الخطوات التالية:

    أزِل الإعداد الذي أضفته سابقًا من الملف /opt/apigee/customer/application/cassandra.properties.

  6. ابدأ خدمة Cassandra على العقدة:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
  7. كرِّر الخطوات على كل عقدة Cassandra تريد التراجع عنها باستخدام النُسخ الاحتياطية، واحدة تلو الأخرى.

  8. بعد استعادة جميع عُقد Cassandra، أعِد تشغيل جميع مكوّنات edge-* واحدًا تلو الآخر:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
            

تحسينات النسخ الاحتياطي (خيار متقدّم)

يمكنك تقليل (أو منع) فقدان البيانات أثناء استعادة النُسخ الاحتياطية إذا كانت لديك نُسخ طبق الأصل متاحة تحتوي على أحدث البيانات. إذا كانت النُسخ المتماثلة متاحة، شغِّل عملية إصلاح على العُقدة التي تم استعادتها بعد استعادة النسخة الاحتياطية.

الملحق

كيفية تحديد العُقد الأولية

على أي عقدة Cassandra في مركز بيانات، نفِّذ الأمر التالي:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

سيعرض الأمر عدة أسطر. ابحث عن السطر الأخير من الناتج. عناوين IP المُدرَجة في السطر الأخير هي عُقد البداية. في المثال أدناه، DC-1-IP1 وDC-1-IP2 وDC-2-IP1 وDC-2-IP2 هي عناوين IP لعقدة البداية:

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

التراجع عن تحديث Zookeeper 3.8.4

العودة إلى الإصدار السابق

في حال الحاجة إلى التراجع عن التغييرات:

  1. نفِّذ خطوات التراجع على المراقبين والمتابعين أولاً.
  2. نزِّل عملية bootstrap الخاصة بالإصدار الذي تريد الرجوع إليه ونفِّذها، أي الإصدار 4.52.02 أو 4.53.00. من المحتمل أن تختلف العملية حسب ما إذا كانت العقدة متصلة بالإنترنت خارجيًا أو كنت تتّبع عملية التثبيت بلا إنترنت.
  3. أوقِف Zookeeper إذا كان قيد التشغيل على العقدة:
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. ألغِ تثبيت zookeeper الحالي:
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. ثبِّت Zookeeper كالمعتاد:
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. بعد إرجاع جميع العُقد التابعة والعُقد المراقبة إلى الإصدار السابق، أرجِع العُقدة الرئيسية إلى الإصدار السابق باتّباع الخطوات من 2 إلى 5 على العُقدة الرئيسية.
  7. بعد إرجاع جميع العُقد إلى الإصدار السابق، تحقَّق من سلامة المجموعة وتأكَّد من توفّر عقدة رئيسية فيها.

استعادة النسخة الاحتياطية

راجِع مقالة الاستعادة من نسخة احتياطية. يُرجى العِلم أنّ عمليات النسخ الاحتياطي لـ Zookeeper التي تم إجراؤها من إصدارات سابقة من Edge for Private Cloud، مثل 4.52.02 أو 4.53.00، يجب أن تكون متوافقة مع إصدار Zookeeper في Edge for Private Cloud 4.53.01.

التراجع عن تحديث Postgres 17

إذا تمت الترقية إلى الإصدار 4.53.01 من الإصدار 4.52.02 أو 4.53.00، عليك الرجوع إلى إصدار Postgres السابق بالإضافة إلى مكونات Edge.

لإرجاع تحديث Postgres عند تحديث Postgres في إعدادات رئيسية احتياطية، اتّبِع الخطوات التالية:

  • ترقية العقدة الاحتياطية الجديدة لتصبح عقدة Postgres الرئيسية سيكون إصدار Postgres الرئيسي الجديد هو نفسه إصدار Edge السابق.
  • اضبط عقدة الاستعداد القديمة لتكون عقدة استعداد للعقدة الرئيسية الجديدة. سيكون إصدار عقدة الاستعداد القديمة هو الإصدار نفسه الذي تم تثبيت Edge عليه سابقًا.
  • سجِّل العقدتَين الرئيسية والاحتياطية الجديدتَين مع مجموعتَي الإحصاءات والمستهلكين.

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

قبل البدء

قبل تنفيذ عملية الرجوع من Postgres 17 إلى 14، اتّبِع الخطوات التالية على كل من المضيف الاحتياطي الجديد والاحتياطي القديم لتعديل السمة max_locks_per_transaction في apigee-postgresql:

  1. إذا لم يكن الملف متوفّرًا، أنشِئ الملف /opt/apigee/customer/application/postgresql.properties
  2. غيِّر ملكية هذا الملف إلى apigee:
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. أضِف السمة التالية إلى الملف:
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. اضبط إعدادات apigee-postgresql:
    apigee-service apigee-postgresql configure
  5. أعِد تشغيل apigee-postgresql:
    apigee-service apigee-postgresql restart
  1. تأكَّد من أنّ عقدة Postgres الاحتياطية الجديدة تعمل:
    /opt/apigee/apigee-service/bin/apigee-all status

    إذا لم يكن Postgres قيد التشغيل، ابدأ تشغيله:

    /opt/apigee/apigee-service/bin/apigee-all start
  2. تأكَّد من إيقاف Postgres على العقدة الرئيسية القديمة وعقدة النسخ الاحتياطي القديمة:
    /opt/apigee/apigee-service/bin/apigee-all status

    إذا كان Postgres قيد التشغيل، أوقِفه:

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. إذا كان Qpid مثبَّتًا، ابدأ تشغيله على عقدة الاستعداد القديمة:
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. ترقية العقدة الاحتياطية الجديدة لتصبح العقدة الرئيسية في Postgres:
    1. ترقية عقدة الاستعداد الجديدة لتصبح العقدة الرئيسية الجديدة:
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      إذا طُلب منك ذلك، أدخِل كلمة مرور Postgres الخاصة بالمستخدم "apigee"، والتي تكون القيمة التلقائية لها هي "postgres".

    2. عدِّل ملف الإعداد الذي استخدمته لتثبيت الإصدار الحالي من Edge لتحديد ما يلي:
      # IP address of the new master:
      PG_MASTER=new_standby_IP
      # IP address of the old standby node
      PG_STANDBY=old_standby_IP
    3. اضبط المستند الرئيسي الجديد:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. إذا سبق لك ترقية عُقدة الاستعداد القديمة إلى الإصدار الأحدث، عليك أولاً الرجوع إلى إصدار أقدم من برنامج Apigee على عُقدة الاستعداد القديمة. إذا كان الإصدار القديم لا يزال مثبّتًا على العقدة الاحتياطية القديمة، يمكنك تخطّي هذه الخطوة والمتابعة إلى الخطوة 6.
    1. أوقِف Postgres على عقدة الاستعداد القديمة:
      apigee-service apigee-postgresql stop
      apigee-service edge-postgres-server stop
    2. ألغِ تثبيت Postgres من عقدة النسخة الاحتياطية القديمة:
      apigee-service apigee-postgresql uninstall
      apigee-service edge-postgres-server uninstall
    3. احذف دليل بيانات Postgres من عقدة النسخة الاحتياطية القديمة:
      cd /opt/apigee/data/apigee-postgresql/pgdata
      rm -rf *
    4. نزِّل وشغِّل برنامج الإعداد الأقدم (للإصدار الذي تريد الرجوع إليه) على عقدة الاستعداد القديمة. قد تختلف الخطوات الدقيقة حسب ما إذا كنت تستخدم عملية تثبيت تستند إلى الإنترنت أو عملية تثبيت بلا اتصال بالإنترنت. سيؤدي تشغيل الإصدار القديم من Apigee bootstrap إلى إعداد مستودعات yum باستخدام بيانات الإصدار القديم من Apigee.
    5. اضبط مكوّنات Postgres على عقدة النسخة الاحتياطية القديمة:
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. تحقَّق من أنّ مكونات Postgres على عقدة النسخة الاحتياطية القديمة تمت إعادتها إلى الإصدار الأقدم:
      apigee-service apigee-postgresql version
      apigee-service edge-postgres-server version
  6. إعادة إنشاء عقدة الاستعداد القديمة:
    1. عدِّل ملف الإعداد الذي استخدمته لتثبيت الإصدار الحالي من Edge لتحديد ما يلي:
      # IP address of the new master:
      PG_MASTER=new_standby_IP
      # IP address of the old standby node
      PG_STANDBY=old_standby_IP
    2. أزِل دليل البيانات على عقدة النسخة الاحتياطية القديمة:
      cd /opt/apigee/data/apigee-postgresql/pgdata
      rm -rf *
    3. أعِد ضبط عقدة الاستعداد القديمة لتكون عقدة احتياطية للعقدة الرئيسية الجديدة:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. تأكَّد من أنّ Postgres يعمل على عقدة النسخة الاحتياطية القديمة:
      /opt/apigee/apigee-service/bin/apigee-all status

      إذا لم يكن Postgres قيد التشغيل، ابدأ تشغيله:

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. تأكَّد من أنّه تمت إضافة العقدة الاحتياطية الجديدة من خلال عرض ملف /opt/apigee/apigee-postgresql/conf/pg_hba.conf على العقدة الرئيسية الجديدة.
  8. يمكنك عرض معلومات التحليلات ومجموعة المستهلكين الحالية من خلال تنفيذ الأمر التالي على خادم الإدارة:
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    يعرض هذا الأمر اسم مجموعة الإحصاءات في الحقل name، واسم مجموعة المستهلكين في الحقل name ضمن consumer-groups. تعرض هذه السمة أيضًا أرقام التعريف الفريدة العالمية (UUID) للعقد الرئيسية والاحتياطية القديمة في Postgres في الحقل postgres-server وفي الحقل datastores. من المفترض أن يظهر لك الناتج بالتنسيق التالي:

    {
      "name" : "axgroup-001",
      "properties" : {
      },
      "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
      "uuids" : {
        "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
        "postgres-server" : [
          "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
        ]
      },
      "consumer-groups" : [ {
        "name" : "consumer-group-001",
        "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
        "datastores" :
          [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
          "properties" : {     }
        }
      ],
      "data-processors" : {
      }
    }
  9. احصل على عنوان UUID للعقدة الرئيسية القديمة من خلال تنفيذ الأمر curl التالي على عقدة العقدة الرئيسية القديمة:
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    من المفترض أن يظهر لك المعرّف الفريد العالمي (UUID) للعقدة في نهاية الناتج، بالشكل التالي:

    "type" : [ "postgres-server" ],
    "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. كرِّر الخطوة السابقة للحصول على عناوين IP الخاصة بعقدة الاستعداد القديمة والعقدة الرئيسية الجديدة.
  11. أزِل العُقد الرئيسية والاحتياطية القديمة من مجموعة المستهلكين:
    curl -u sysAdminEmail:password -X DELETE \
      "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    حيث يمثّل axgroup-001 وconsumer-group-001 الأسماء التلقائية لمجموعتَي التحليلات والمستهلكين. masterUUID,standbyUUID بالترتيب نفسه الذي ظهرت به أعلاه عند عرض الإحصاءات الحالية ومعلومات مجموعة المستهلكين أعلاه. قد تحتاج إلى تحديدها على أنّها standbyUUID,masterUUID.

    يجب أن تكون الخاصية datastores الخاصة بـ consumer-groups فارغة الآن.

  12. أزِل العُقد الرئيسية والاحتياطية القديمة من مجموعة الإحصاءات:
    curl -u sysAdminEmail:password -X DELETE \
      "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    يجب أن تكون الخاصية postgres-server ضمن uuids فارغة الآن.

  13. سجِّل عقدتَي PG الرئيسية والاحتياطية الجديدتَين مع مجموعتَي "الإحصاءات" و"المستهلكين":
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
      "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
    curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
      "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. إثبات صحة مجموعة الإحصاءات:
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    من المفترض أن تظهر لك المعرّفات الفريدة الشاملة (UUID) للعقدة الرئيسية الجديدة والعقدة الاحتياطية في مجموعة الإحصاءات ومجموعة المستهلكين.

  15. أعِد تشغيل خادم إدارة Edge:
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. أعِد تشغيل جميع خوادم Qpid:
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. أعِد تشغيل جميع خوادم Postgres:
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. تحقَّق من حالة النسخ المتماثل من خلال تنفيذ النصوص البرمجية التالية على كلا الخادمَين. يجب أن يعرض النظام نتائج متطابقة على كلا الخادمَين لضمان نجاح عملية النسخ المتماثل:

    على الجهاز الرئيسي الجديد، نفِّذ ما يلي:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    تأكَّد من أنّها هي النسخة الرئيسية. على عُقدة النسخ الاحتياطي القديمة، اتّبِع الخطوات التالية:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    تأكَّد من أنّها النسخة الاحتياطية.

  19. كرِّر الخطوة السابقة بعد تقديم عدة طلبات إلى واجهة برمجة التطبيقات للتأكّد من أنّ العُقد متزامنة.
  20. أوقِف خادم Postgres الرئيسي القديم نهائيًا باتّباع الإجراءات الواردة في إيقاف عقدة Postgres نهائيًا.

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

التراجع عن تحديث LDAP 2.6

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

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

المتطلّبات الأساسية والاعتبارات

  • عدم توافق النسخ الاحتياطية: استخدِم نسخة احتياطية من إصدار LDAP الأقدم 2.4 الذي كنت تستخدمه مع Edge for Private Cloud 4.52.02 أو 4.53.00. يجب أن تكون قد أجريت عملية النسخ الاحتياطي هذه قبل محاولة الترقية. النُسخ الاحتياطية التي تم إنشاؤها بعد الترقية غير متوافقة ولا يمكن استخدامها.
  • تعطُّل Management API: أثناء عملية التراجع عن LDAP، ستكون واجهات برمجة التطبيقات الإدارية غير متاحة، ما قد يؤثر في المهام الإدارية. يُرجى التأكّد من إيقاف جميع خوادم إدارة الحافة وواجهة مستخدم الحافة قبل المتابعة في عملية الرجوع إلى إصدار LDAP السابق.
  • خطر فقدان البيانات: قد يؤدي المتابعة بدون نسخة احتياطية صالحة ومتوافقة إلى فقدان البيانات بشكل لا يمكن استرجاعه.
  • نسخة احتياطية صالحة: يجب توفّر نسخة احتياطية صالحة من LDAP قبل الترقية.

إجراءات العودة إلى الإصدار السابق

  1. يُرجى التأكّد من إيقاف جميع خوادم إدارة الحافة وواجهة مستخدم الحافة قبل المتابعة في ترقية LDAP.
    apigee-service edge-management-server stop
    apigee-service edge-ui stop
  2. الاحتفاظ بنسخة احتياطية من بيانات LDAP الحالية (قبل إيقاف LDAP)

    الحصول على إجمالي عدد السجلات كمرجع من جميع خوادم ldap (يجب أن يتطابق عدد السجلات على جميع خوادم LDAP)

          # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password. 
    ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. إيقاف الإصدار الجديد من LDAP 2.6 وإلغاء تثبيته

    أوقِف خدمة apigee-openldap واحذف أدلة الإعدادات والبيانات. يجب إجراء ذلك على جميع خوادم LDAP، وعقدة واحدة في كل مرة في المجموعة لضمان الاتساق.

    apigee-service apigee-openldap stop
    apigee-service apigee-openldap uninstall
    rm -rf /opt/apigee/data/apigee-openldap/*
  4. تثبيت الإصدار القديم 2.4 من LDAP
    • تثبيت إصدار LDAP القديم:
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • التحقّق من صحة إصدار LDAP:
      source ~/.bash_profile
      ldapsearch -VV
      
      #Expected output:
      ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
    • كرِّر الخطوات أعلاه على كل عقدة LDAP، واحدة تلو الأخرى
  5. تنظيف البيانات المتبقية

    على جميع خوادم LDAP، أوقِف الخدمة المثبَّتة حديثًا واحدة تلو الأخرى ونظِّف دليل البيانات الخاص بها استعدادًا للاستعادة من النسخة الاحتياطية.

    apigee-service apigee-openldap stop
    rm -rf /opt/apigee/data/apigee-openldap/*
  6. استعادة بيانات LDAP

    بالنسبة إلى عملية الإعداد على خادم واحد، يمكنك الانتقال مباشرةً إلى الخطوة 5b. بالنسبة إلى عملية إعداد خوادم متعددة، انتقِل إلى الخطوة 5أ.

    1. تحديد خادم LDAP النشط

      قبل استعادة بيانات LDAP، حدِّد الخادم النشط (المزوّد) من خلال تنفيذ هذا الأمر.

      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
      
      * **Note**:
      * If this command returns output, the server is a passive server. 
      * If it returns no output, the server is the active server.
    2. استعادة بيانات LDAP (يجب التأكّد من إكمال الخطوة 4 على جميع الخوادم قبل الاستعادة)
      • على خادم LDAP الفردي والنشط (الذي تم تحديده في الخطوة 5أ)، استعِد النسخة الاحتياطية.
        cd /opt/apigee/backup/openldap
        
        # To restore a specific backup, provide the timestamp as shown below:
        apigee-service apigee-openldap restore 2025.07.28,13.59.00
        # Note: If no timestamp is provided, the latest available backup will be restored by default.
        apigee-service apigee-openldap restore
        
        # It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • ابدأ خدمة apigee-openldap.
        apigee-service apigee-openldap start
  7. بدء تشغيل خوادم LDAP المتبقية

    في حال إعداد خوادم متعددة، ابدأ الخدمة على كل خادم من خوادم LDAP:

    apigee-service apigee-openldap start
  8. التحقّق النهائي من الصحة
    • الخطوة الأخيرة هي التأكّد من أنّ عملية الرجوع إلى الإصدار السابق تمت بنجاح وأنّ البيانات متسقة في جميع مجموعات LDAP.
    • نفِّذ أمر التحقّق من الصحة على جميع خوادم LDAP. يجب أن يكون عدد السجلات متطابقًا على جميع الخوادم ويجب أن يتطابق مع العدد الذي سجّلته في الخطوة 1.
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
      ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • بعد التأكّد من صحة البيانات واتساقها، يكتمل التراجع عن LDAP. يمكنك الآن المتابعة وبدء edge-management-server وedge-ui وأي مكونات أخرى تابعة وفقًا لإجراءات الترقية العادية في مؤسستك.

العودة إلى إصدار رئيسي أو ثانوي سابق

للتراجع إلى إصدار رئيسي أو ثانوي سابق، اتّبِع الخطوات التالية على كل عقدة تستضيف المكوّن:

  1. نزِّل ملف bootstrap.sh للنسخة التي تريد الرجوع إليها:

    • للتراجع إلى الإصدار 4.52.02، نزِّل bootstrap_4.52.02.sh
  2. أوقِف المكوّن المطلوب التراجع عنه:
    1. للتراجع عن أي من المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا على عقدة، يجب إيقافها كلها، كما هو موضّح في المثال التالي:
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
      /opt/apigee/apigee-service/bin/apigee-service edge-router stop
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
      /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. لإرجاع أي مكوّن آخر على العقدة، أوقِف هذا المكوّن فقط:
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. إذا كنت بصدد التراجع عن تفعيل ميزة تحقيق الربح، عليك إلغاء تثبيتها من جميع عقد خادم الإدارة ومعالج الرسائل باتّباع الخطوات التالية:
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. ألغِ تثبيت المكوّن للرجوع إلى الإصدار السابق على العُقدة:
    1. للتراجع عن أي من المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا على عقدة ، عليك إلغاء تثبيتها كلها من خلال إلغاء تثبيت مجموعة المكوّنات edge-gateway وapigee-cassandra-client، كما يوضّح المثال التالي:
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. للتراجع عن Nginx، اتّبِع الخطوات التالية:
      ###Find the apigee-nginx RPM 
      rpm -qa | grep -i "apigee-nginx"
      
      ###Remove the apigee-nginx RPM
      dnf remove apigee-nginx-1.26.x
      
    3. للتراجع عن أي مكون آخر على العقدة، عليك إلغاء تثبيت هذا المكون فقط، كما يوضّح المثال التالي:
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      حيث component هو اسم المكوّن.

    4. لإرجاع Edge Router إلى الإصدار السابق، عليك حذف محتوى الملف /opt/nginx/conf.d بالإضافة إلى إلغاء تثبيت مجموعة المكوّنات edge-gateway:
      cd /opt/nginx/conf.d
      rm -rf *
  5. ألغِ تثبيت الإصدار 4.53.01 من apigee-setup باتّباع الخطوات التالية:
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. ثبِّت الإصدار 4.52.02 من الأداة المساعدة apigee-service وتبعياته. يوضّح المثال التالي كيفية تثبيت الإصدار 4.52.02 من apigee-service:
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    حيث يمثّل uName وpWord اسم المستخدم وكلمة المرور اللذين تلقّيتهما من Apigee. إذا حذفت pWord، سيُطلب منك إدخاله.

    إذا ظهرت لك رسالة خطأ، تأكَّد من أنّك نزّلت ملف bootstrap.sh في الخطوة 1.

  7. تثبيت apigee-setup:
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. ثبِّت الإصدار الأقدم من المكوّن:
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    حيث component هو المكوّن الذي سيتم تثبيته، وconfigFile هو ملف الإعداد الخاص بالإصدار القديم.

  9. إذا كنت بصدد إرجاع Qpid إلى الإصدار السابق، عليك محو iptables:
    sudo iptables -F
  10. كرِّر هذه العملية لكل عقدة تستضيف المكوّن الذي تريد التراجع عنه.

العودة إلى الإصدار السابق من mTLS

للتراجع عن تحديث mTLS، اتّبِع الخطوات التالية على جميع المضيفين:

  1. إيقاف Apigee:
    apigee-all stop
  2. إيقاف mTLS:
    apigee-service apigee-mtls uninstall
  3. أعِد تثبيت mTLS:
    apigee-service apigee-mtls install
    apigee-service apigee-mtls setup -f /opt/silent.conf