إذا حدث خطأ أثناء تحديث 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 على النحو التالي:
- إرجاع Qpid والمكوّنات الأخرى ذات الصلة بالإحصاءات وPostgres إلى الإصدار السابق
- إعادة أجهزة التوجيه ومعالجات الرسائل إلى الحالة السابقة
- العودة إلى الإصدار السابق من Cassandra وZookeeper
- خادم إدارة العودة إلى الإصدار السابق
- العودة إلى إعدادات 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. يجب أن تكون مستعدًا لتحويل عدد الزيارات في وقت التشغيل بعيدًا عن مركز البيانات هذا أثناء عملية التراجع.
الخطوات العامة
- اختَر مركز بيانات واحدًا (تمت ترقيته جزئيًا أو كليًا) تريد التراجع عنه. توجيه زيارات وقت التشغيل إلى مركز بيانات آخر يعمل
- حدِّد عقدة البداية في مركز البيانات وابدأ بإحدى عقد البداية.
- أوقِف عقدة Cassandra وألغِ تثبيتها ونظِّفها.
- ثبِّت الإصدار الأقدم من Cassandra على العُقدة واضبطه حسب الحاجة.
- أزِل الإعدادات الإضافية التي تمت إضافتها سابقًا.
- كرِّر الخطوات المذكورة أعلاه لجميع العُقد الأولية في مركز البيانات، واحدة تلو الأخرى.
- كرِّر الخطوات أعلاه لجميع عُقد Cassandra المتبقية في مركز البيانات، واحدة تلو الأخرى.
- إعادة إنشاء العُقد من مركز البيانات الوظيفي الحالي، واحدة تلو الأخرى
- أعِد تشغيل جميع مكونات edge-* في مركز البيانات المرتبطة بـ Cassandra.
- اختبِر حركة المرور وأعِد توجيهها إلى مركز البيانات هذا.
- كرِّر الخطوات لكل مركز بيانات، واحدًا تلو الآخر.
الخطوات التفصيلية
-
اختَر مركز بيانات واحدًا تتم فيه ترقية بعض أو كل عُقد 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] - تحديد العُقد الأولية في مركز البيانات: يُرجى الرجوع إلى القسم كيفية تحديد العُقد الأولية في الملحق. نفِّذ الخطوات أدناه على إحدى عُقد البداية:
- إيقاف وإلغاء تثبيت البيانات وتنظيفها من عقدة 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 datarm -rf /opt/apigee/data/apigee-cassandra
- ثبِّت برنامج Cassandra القديم على العُقدة واضبط بعض الإعدادات. نفِّذ ملف bootstrap الخاص بالإصدار 4.52.02 من Edge for Private Cloud.
- أنشئ الملف
/opt/apigee/customer/application/cassandra.properties
أو عدِّله. - أضِف المحتوى التالي إلى الملف.
ipOfNode
هو عنوان IP للعقدة التي تستخدمها Cassandra للتواصل مع عُقد Cassandra الأخرى: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 وأعِدّها على النحو التالي:
- تأكَّد من بدء تشغيل العُقدة. تحقَّق من الأمر التالي على هذه العُقدة والعُقد الأخرى في المجموعة. يجب أن تشير العقدة إلى أنّها في الحالة "UN" (نشطة/عادية):
/opt/apigee/apigee-cassandra/bin/nodetool status
- أزِل الإعدادات الإضافية التي أضفتها سابقًا من الملف
/opt/apigee/customer/application/cassandra.properties
. - كرِّر الخطوات من 3 إلى 10 على جميع عقد البذور في Cassandra في مركز البيانات، واحدة تلو الأخرى.
- كرِّر الخطوات من 3 إلى 10 على جميع عُقد Cassandra المتبقية في مركز البيانات، واحدة تلو الأخرى.
- أعِد إنشاء جميع العُقد في مركز البيانات من مركز بيانات يعمل بإصدار Cassandra الأقدم. نفِّذ هذه الخطوة على عقدة واحدة في كل مرة:
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
قد يستغرق هذا الإجراء بعض الوقت. يمكنك تعديل
streamingthroughput
إذا لزم الأمر. اطّلِع علىnodetool netstats
لمعرفة حالة اكتمال العملية. - (اختياري) نفِّذ أمر الإصلاح في عقدة Cassandra إذا لم تتم إعادة إنشاء البيانات.
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
- أعِد تشغيل جميع مكوّنات 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
- التحقّق من صحة مركز البيانات هذا وإعادة توجيه الزيارات إليه إجراء بعض عمليات التحقّق من صحة بيانات الزيارات في وقت التشغيل وواجهات برمجة التطبيقات الإدارية في مركز البيانات هذا، وبدء إعادة توجيه الزيارات إلى الخادم الوكيل وواجهة برمجة التطبيقات الإدارية إليه
- كرِّر الخطوات أعلاه لكل مركز بيانات تريد التراجع عنه.
# Download bootstrap of 4.52.02curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord
# Execute bootstrap of 4.52.02sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
# 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
العودة إلى الإصدار السابق من Cassandra باستخدام نسخة احتياطية
المتطلبات الأساسية
- أنت بصدد ترقية Cassandra من الإصدار 3.11.X إلى الإصدار 4.0.X وواجهت مشاكل أثناء الترقية.
- يجب أن تتوفّر لديك نُسخ احتياطية للعُقدة التي تريد العودة إلى إصدارها السابق. تم إنشاء النسخة الاحتياطية قبل محاولة الترقية من الإصدار 3.11.X إلى الإصدار 4.0.X.
الخطوات
اختَر عقدة واحدة تريد التراجع عنها. إذا كنت بصدد إرجاع جميع العُقد في مركز بيانات باستخدام نُسخ احتياطية، ابدأ بعُقد البداية أولاً. راجِع القسم "كيفية تحديد العُقد الأولية" في الملحق.
أوقِف عقدة 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 datarm -rf /opt/apigee/data/apigee-cassandra
ثبِّت برنامج Cassandra القديم على العقدة واضبطه:
- نفِّذ ملف bootstrap لإصدار Edge for Private Cloud 4.52.02:
- أنشئ الملف
/opt/apigee/customer/application/cassandra.properties
أو عدِّله: - تأكَّد من أنّ ملف المفتاح يملكه مستخدم Apigee ويمكن قراءته:
- ثبِّت Cassandra وأعِدّها على النحو التالي:
# 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.02sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
# 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
أوقِف خدمة Cassandra واستعِد النسخة الاحتياطية. يُرجى الرجوع إلى مستندات الاحتفاظ بنسخة احتياطية من البيانات واستعادتها للحصول على مزيد من التفاصيل:
# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
# Wipe the data directory in preparation for restorerm -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
بعد استعادة النسخة الاحتياطية، أزِل الإعدادات الإضافية باتّباع الخطوات التالية:
أزِل الإعداد الذي أضفته سابقًا من الملف
/opt/apigee/customer/application/cassandra.properties
.ابدأ خدمة Cassandra على العقدة:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
كرِّر الخطوات على كل عقدة Cassandra تريد التراجع عنها باستخدام النُسخ الاحتياطية، واحدة تلو الأخرى.
بعد استعادة جميع عُقد 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
العودة إلى الإصدار السابق
في حال الحاجة إلى التراجع عن التغييرات:
- نفِّذ خطوات التراجع على المراقبين والمتابعين أولاً.
- نزِّل عملية bootstrap الخاصة بالإصدار الذي تريد الرجوع إليه ونفِّذها، أي الإصدار 4.52.02 أو 4.53.00. من المحتمل أن تختلف العملية حسب ما إذا كانت العقدة متصلة بالإنترنت خارجيًا أو كنت تتّبع عملية التثبيت بلا إنترنت.
- أوقِف Zookeeper إذا كان قيد التشغيل على العقدة:
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
- ألغِ تثبيت zookeeper الحالي:
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
- ثبِّت Zookeeper كالمعتاد:
/opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
- بعد إرجاع جميع العُقد التابعة والعُقد المراقبة إلى الإصدار السابق، أرجِع العُقدة الرئيسية إلى الإصدار السابق باتّباع الخطوات من 2 إلى 5 على العُقدة الرئيسية.
- بعد إرجاع جميع العُقد إلى الإصدار السابق، تحقَّق من سلامة المجموعة وتأكَّد من توفّر عقدة رئيسية فيها.
استعادة النسخة الاحتياطية
راجِع مقالة الاستعادة من نسخة احتياطية. يُرجى العِلم أنّ عمليات النسخ الاحتياطي لـ 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
:
- إذا لم يكن الملف متوفّرًا، أنشِئ الملف
/opt/apigee/customer/application/postgresql.properties
- غيِّر ملكية هذا الملف إلى apigee:
sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
- أضِف السمة التالية إلى الملف:
conf/postgresql.conf+max_locks_per_transaction=30000
- اضبط إعدادات apigee-postgresql:
apigee-service apigee-postgresql configure
- أعِد تشغيل apigee-postgresql:
apigee-service apigee-postgresql restart
- تأكَّد من أنّ عقدة Postgres الاحتياطية الجديدة تعمل:
/opt/apigee/apigee-service/bin/apigee-all status
إذا لم يكن Postgres قيد التشغيل، ابدأ تشغيله:
/opt/apigee/apigee-service/bin/apigee-all start
- تأكَّد من إيقاف 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
- إذا كان Qpid مثبَّتًا، ابدأ تشغيله على عقدة الاستعداد القديمة:
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
- ترقية العقدة الاحتياطية الجديدة لتصبح العقدة الرئيسية في Postgres:
- ترقية عقدة الاستعداد الجديدة لتصبح العقدة الرئيسية الجديدة:
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
إذا طُلب منك ذلك، أدخِل كلمة مرور Postgres الخاصة بالمستخدم "apigee"، والتي تكون القيمة التلقائية لها هي "postgres".
- عدِّل ملف الإعداد الذي استخدمته لتثبيت الإصدار الحالي من Edge لتحديد ما يلي:
# IP address of the new master: PG_MASTER=new_standby_IP # IP address of the old standby node PG_STANDBY=old_standby_IP
- اضبط المستند الرئيسي الجديد:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
- ترقية عقدة الاستعداد الجديدة لتصبح العقدة الرئيسية الجديدة:
- إذا سبق لك ترقية عُقدة الاستعداد القديمة إلى الإصدار الأحدث، عليك أولاً الرجوع إلى إصدار أقدم من برنامج Apigee على عُقدة الاستعداد القديمة. إذا كان الإصدار القديم لا يزال مثبّتًا على العقدة الاحتياطية القديمة، يمكنك تخطّي هذه الخطوة والمتابعة إلى الخطوة 6.
- أوقِف Postgres على عقدة الاستعداد القديمة:
apigee-service apigee-postgresql stop apigee-service edge-postgres-server stop
- ألغِ تثبيت Postgres من عقدة النسخة الاحتياطية القديمة:
apigee-service apigee-postgresql uninstall apigee-service edge-postgres-server uninstall
- احذف دليل بيانات Postgres من عقدة النسخة الاحتياطية القديمة:
cd /opt/apigee/data/apigee-postgresql/pgdata rm -rf *
- نزِّل وشغِّل برنامج الإعداد الأقدم (للإصدار الذي تريد الرجوع إليه) على عقدة الاستعداد القديمة. قد تختلف الخطوات الدقيقة حسب ما إذا كنت تستخدم عملية تثبيت تستند إلى الإنترنت أو عملية تثبيت بلا اتصال بالإنترنت. سيؤدي تشغيل الإصدار القديم من Apigee bootstrap إلى إعداد مستودعات yum باستخدام بيانات الإصدار القديم من Apigee.
- اضبط مكوّنات Postgres على عقدة النسخة الاحتياطية القديمة:
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
- تحقَّق من أنّ مكونات Postgres على عقدة النسخة الاحتياطية القديمة
تمت إعادتها إلى الإصدار الأقدم:
apigee-service apigee-postgresql version apigee-service edge-postgres-server version
- أوقِف Postgres على عقدة الاستعداد القديمة:
- إعادة إنشاء عقدة الاستعداد القديمة:
- عدِّل ملف الإعداد الذي استخدمته لتثبيت الإصدار الحالي من Edge لتحديد ما يلي:
# IP address of the new master: PG_MASTER=new_standby_IP # IP address of the old standby node PG_STANDBY=old_standby_IP
- أزِل دليل البيانات على عقدة النسخة الاحتياطية القديمة:
cd /opt/apigee/data/apigee-postgresql/pgdata rm -rf *
- أعِد ضبط عقدة الاستعداد القديمة لتكون عقدة احتياطية للعقدة الرئيسية الجديدة:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
- تأكَّد من أنّ Postgres يعمل على عقدة النسخة الاحتياطية القديمة:
/opt/apigee/apigee-service/bin/apigee-all status
إذا لم يكن Postgres قيد التشغيل، ابدأ تشغيله:
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
- عدِّل ملف الإعداد الذي استخدمته لتثبيت الإصدار الحالي من Edge لتحديد ما يلي:
- تأكَّد من أنّه تمت إضافة العقدة الاحتياطية الجديدة من خلال عرض ملف
/opt/apigee/apigee-postgresql/conf/pg_hba.conf
على العقدة الرئيسية الجديدة. - يمكنك عرض معلومات التحليلات ومجموعة المستهلكين الحالية من خلال تنفيذ الأمر التالي
على خادم الإدارة:
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" : { } }
- احصل على عنوان UUID للعقدة الرئيسية القديمة من خلال تنفيذ الأمر
curl
التالي على عقدة العقدة الرئيسية القديمة:curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
من المفترض أن يظهر لك المعرّف الفريد العالمي (UUID) للعقدة في نهاية الناتج، بالشكل التالي:
"type" : [ "postgres-server" ], "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
- كرِّر الخطوة السابقة للحصول على عناوين IP الخاصة بعقدة الاستعداد القديمة والعقدة الرئيسية الجديدة.
- أزِل العُقد الرئيسية والاحتياطية القديمة من مجموعة المستهلكين:
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
فارغة الآن. - أزِل العُقد الرئيسية والاحتياطية القديمة من مجموعة الإحصاءات:
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
فارغة الآن. - سجِّل عقدتَي 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
- إثبات صحة مجموعة الإحصاءات:
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
من المفترض أن تظهر لك المعرّفات الفريدة الشاملة (UUID) للعقدة الرئيسية الجديدة والعقدة الاحتياطية في مجموعة الإحصاءات ومجموعة المستهلكين.
- أعِد تشغيل خادم إدارة Edge:
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
- أعِد تشغيل جميع خوادم Qpid:
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
- أعِد تشغيل جميع خوادم Postgres:
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
- تحقَّق من حالة النسخ المتماثل من خلال تنفيذ النصوص البرمجية التالية على كلا الخادمَين. يجب أن يعرض النظام نتائج متطابقة على كلا الخادمَين لضمان نجاح عملية النسخ المتماثل:
على الجهاز الرئيسي الجديد، نفِّذ ما يلي:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
تأكَّد من أنّها هي النسخة الرئيسية. على عُقدة النسخ الاحتياطي القديمة، اتّبِع الخطوات التالية:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
تأكَّد من أنّها النسخة الاحتياطية.
- كرِّر الخطوة السابقة بعد تقديم عدة طلبات إلى واجهة برمجة التطبيقات للتأكّد من أنّ العُقد متزامنة.
- أوقِف خادم 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 قبل الترقية.
إجراءات العودة إلى الإصدار السابق
- يُرجى التأكّد من إيقاف جميع خوادم إدارة الحافة وواجهة مستخدم الحافة قبل المتابعة في ترقية LDAP.
apigee-service edge-management-server stop apigee-service edge-ui stop
- الاحتفاظ بنسخة احتياطية من بيانات 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
- إيقاف الإصدار الجديد من LDAP 2.6 وإلغاء تثبيته
أوقِف خدمة
apigee-openldap
واحذف أدلة الإعدادات والبيانات. يجب إجراء ذلك على جميع خوادم LDAP، وعقدة واحدة في كل مرة في المجموعة لضمان الاتساق.apigee-service apigee-openldap stop apigee-service apigee-openldap uninstall rm -rf /opt/apigee/data/apigee-openldap/*
- تثبيت الإصدار القديم 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، واحدة تلو الأخرى
- تثبيت إصدار LDAP القديم:
- تنظيف البيانات المتبقية
على جميع خوادم LDAP، أوقِف الخدمة المثبَّتة حديثًا واحدة تلو الأخرى ونظِّف دليل البيانات الخاص بها استعدادًا للاستعادة من النسخة الاحتياطية.
apigee-service apigee-openldap stop rm -rf /opt/apigee/data/apigee-openldap/*
- استعادة بيانات LDAP
بالنسبة إلى عملية الإعداد على خادم واحد، يمكنك الانتقال مباشرةً إلى الخطوة 5b. بالنسبة إلى عملية إعداد خوادم متعددة، انتقِل إلى الخطوة 5أ.
- تحديد خادم 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.
- استعادة بيانات 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
- على خادم LDAP الفردي والنشط (الذي تم تحديده في الخطوة 5أ)، استعِد النسخة الاحتياطية.
- تحديد خادم LDAP النشط
- بدء تشغيل خوادم LDAP المتبقية
في حال إعداد خوادم متعددة، ابدأ الخدمة على كل خادم من خوادم LDAP:
apigee-service apigee-openldap start
- التحقّق النهائي من الصحة
- الخطوة الأخيرة هي التأكّد من أنّ عملية الرجوع إلى الإصدار السابق تمت بنجاح وأنّ البيانات متسقة في جميع مجموعات 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 وأي مكونات أخرى تابعة وفقًا لإجراءات الترقية العادية في مؤسستك.
العودة إلى إصدار رئيسي أو ثانوي سابق
للتراجع إلى إصدار رئيسي أو ثانوي سابق، اتّبِع الخطوات التالية على كل عقدة تستضيف المكوّن:
-
نزِّل ملف
bootstrap.sh
للنسخة التي تريد الرجوع إليها:- للتراجع إلى الإصدار 4.52.02، نزِّل
bootstrap_4.52.02.sh
- للتراجع إلى الإصدار 4.52.02، نزِّل
- أوقِف المكوّن المطلوب التراجع عنه:
- للتراجع عن أي من المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا على عقدة، يجب إيقافها كلها، كما هو موضّح في المثال التالي:
/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
- لإرجاع أي مكوّن آخر على العقدة، أوقِف هذا المكوّن فقط:
/opt/apigee/apigee-service/bin/apigee-service component stop
- للتراجع عن أي من المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا على عقدة، يجب إيقافها كلها، كما هو موضّح في المثال التالي:
- إذا كنت بصدد التراجع عن تفعيل ميزة تحقيق الربح، عليك إلغاء تثبيتها من جميع عقد خادم الإدارة ومعالج الرسائل باتّباع الخطوات التالية:
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- ألغِ تثبيت المكوّن للرجوع إلى الإصدار السابق على العُقدة:
- للتراجع عن أي من المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا على عقدة
، عليك إلغاء تثبيتها كلها من خلال إلغاء تثبيت مجموعة المكوّنات
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
- للتراجع عن Nginx، اتّبِع الخطوات التالية:
###Find the apigee-nginx RPM rpm -qa | grep -i "apigee-nginx" ###Remove the apigee-nginx RPM dnf remove apigee-nginx-1.26.x
- للتراجع عن أي مكون آخر على العقدة، عليك إلغاء تثبيت هذا المكون فقط، كما يوضّح المثال التالي:
/opt/apigee/apigee-service/bin/apigee-service component uninstall
حيث component هو اسم المكوّن.
- لإرجاع Edge Router إلى الإصدار السابق، عليك حذف محتوى الملف
/opt/nginx/conf.d
بالإضافة إلى إلغاء تثبيت مجموعة المكوّناتedge-gateway
:cd /opt/nginx/conf.d
rm -rf *
- للتراجع عن أي من المكوّنات التي تتضمّن رمزًا برمجيًا مشتركًا على عقدة
، عليك إلغاء تثبيتها كلها من خلال إلغاء تثبيت مجموعة المكوّنات
- ألغِ تثبيت الإصدار 4.53.01 من
apigee-setup
باتّباع الخطوات التالية:/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
- ثبِّت الإصدار 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. - تثبيت
apigee-setup
:/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
- ثبِّت الإصدار الأقدم من المكوّن:
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
حيث component هو المكوّن الذي سيتم تثبيته، وconfigFile هو ملف الإعداد الخاص بالإصدار القديم.
- إذا كنت بصدد إرجاع Qpid إلى الإصدار السابق، عليك محو iptables:
sudo iptables -F
- كرِّر هذه العملية لكل عقدة تستضيف المكوّن الذي تريد التراجع عنه.
العودة إلى الإصدار السابق من mTLS
للتراجع عن تحديث mTLS، اتّبِع الخطوات التالية على جميع المضيفين:
- إيقاف Apigee:
apigee-all stop
- إيقاف mTLS:
apigee-service apigee-mtls uninstall
- أعِد تثبيت mTLS:
apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf