החזרה לגרסה קודמת של Apigee Edge 4.53.01

אם נתקלתם בשגיאה במהלך עדכון ל-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 בנפרד
  • ביצוע Rollback של כל אשכול Cassandra באמצעות גיבויים
  • ביצוע Rollback של צמתי שרת Edge Management אחד אחרי השני

מי יכול לבצע חזרה לגרסה קודמת

המשתמש שמבצע את החזרה לגרסה קודמת צריך להיות אותו משתמש שעדכן את Edge במקור, או משתמש שפועל כמשתמש root.

כברירת מחדל, רכיבי Edge פועלים כמשתמש 'apigee'. במקרים מסוימים, יכול להיות שרכיבי Edge יפעלו כמשתמשים שונים. לדוגמה, אם הנתב צריך לגשת ליציאות עם הרשאות, כמו יציאות מתחת ל-1000, צריך להריץ את הנתב כמשתמש root או כמשתמש עם גישה ליציאות האלה. או להריץ רכיב אחד כמשתמש אחד, ורכיב אחר כמשתמש אחר.

רכיבים עם קוד משותף

הרכיבים הבאים של Edge חולקים קוד משותף. לכן, כדי לבצע Rollback לאחד מהרכיבים האלה בצומת, צריך לבצע Rollback לכל הרכיבים האלה שנמצאים באותו צומת.

  • edge-management-server (שרת ניהול)
  • edge-message-processor (מעבד בקשות)
  • edge-router (נתב)
  • ‫edge-postgres-server (Postgres Server)
  • ‫edge-qpid-server (Qpid Server)

לדוגמה, אם התקנתם את שרת הניהול, הנתב ומעבד ההודעות בצומת, כדי לבצע החזרה לאחור של אחד מהם, תצטרכו לבצע החזרה לאחור של כל השלושה.

רולבק של Cassandra

כשמבצעים שדרוג משמעותי של Cassandra בצומת מסוים, Cassandra משנה את הסכימה של הנתונים שמאוחסנים באותו צומת. לכן, אי אפשר לבצע שחזור ישיר במקום.

תרחישי ביטול

‫Cassandra 4.0.X, שזמין ב-Edge for Private Cloud 4.53.01, תואם לרכיבים אחרים של Private Cloud 4.52.02.

בטבלה הבאה מופיע סיכום של אסטרטגיות שונות לביטול שינויים שאפשר להשתמש בהן:

תרחיש אסטרטגיית רולבק
מרכז נתונים יחיד, חלק מצמתי Cassandra שודרגו שימוש בגיבויים
מרכז נתונים יחיד, כל צמתי Cassandra שודרגו אין לחזור לגרסה קודמת של Cassandra. אפשר לבצע החזרה לאחור של רכיבים אחרים.
מרכז נתונים יחיד, כל הצמתים (Cassandra ואחרים) שודרגו אין לחזור לגרסה קודמת של Cassandra. אפשר לבצע החזרה לאחור של רכיבים אחרים.
כמה מרכזי נתונים, חלק מהצמתים במרכז נתונים אחד שודרגו בנייה מחדש מ-DC קיים
מספר מרכזי נתונים, כל צמתי Cassandra בחלק ממרכזי הנתונים שודרגו בנייה מחדש מ-DC קיים
כמה צמתים של Cassandra ב-DC האחרון שמשודרג כדאי לנסות להשלים את השדרוג. אם זה לא אפשרי, מבטלים את השינויים ב-DC אחד באמצעות גיבוי. בנייה מחדש של שאר בקרי הדומיין מבקר הדומיין שהוחזר למצב הקודם.
מספר מרכזי נתונים, כל צמתי Cassandra שודרגו אין לחזור לגרסה קודמת של Cassandra. אפשר לבצע החזרה לאחור של רכיבים אחרים.
שדרוג של כמה מרכזי נתונים, כל הצמתים (Cassandra ואחרים) אין לחזור לגרסה קודמת של Cassandra. אפשר לבצע החזרה לאחור של רכיבים אחרים.

שיקולים כלליים

כששוקלים לבצע חזרה לגרסה קודמת, חשוב לזכור את הנקודות הבאות:

  • חזרה לגרסה קודמת של רכיבי זמן ריצה או ניהול: אם רוצים לחזור לגרסה קודמת של רכיבים כמו edge-management-server,‏ edge-message-processor או כל רכיב שאינו Cassandra לגרסה 4.52.02 של Private Cloud, מומלץ לא לחזור לגרסה קודמת של Cassandra. ‫Cassandra שנשלח עם Private Cloud 4.53.00 תואם לכל הרכיבים שאינם Cassandra של Edge for Private Cloud 4.52.02. אפשר לבצע Rollback לרכיבים שאינם 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, כדאי לשקול חזרה לגרסה קודמת. אפשר לפעול לפי אסטרטגיות החזרה לגרסה הקודמת שמפורטות במאמר הזה, בהתאם למצב שבו אתם נמצאים במהלך תהליך השדרוג.
  • חזרה לגרסה קודמת באמצעות גיבויים: גיבויים שנוצרו מ-Cassandra 4.0.X לא תואמים לגיבויים של Cassandra 3.11.X. כדי לבצע Rollback של Cassandra באמצעות שחזור גיבוי, צריך ליצור גיבויים של Cassandra 3.11.X לפני שמנסים לבצע את השדרוג.

חזרה לגרסה קודמת של Cassandra באמצעות בנייה מחדש

דרישות מוקדמות

  • אתם מפעילים אשכול Edge for Private Cloud 4.52.02 בכמה מרכזי נתונים.
  • אתם בתהליך של שדרוג Cassandra מגרסה 3.11.X לגרסה 4.0.X ונתקלתם בבעיות במהלך השדרוג.
  • יש לכם לפחות מרכז נתונים אחד עם פונקציונליות מלאה באשכול שעדיין מריץ את הגרסה הישנה יותר של Cassandra‏ (Cassandra 3.11.X).

ההליך הזה מסתמך על סטרימינג של נתונים ממרכז נתונים קיים. התהליך הזה עשוי להימשך זמן רב, בהתאם לכמות הנתונים שמאוחסנים ב-Cassandra. במהלך ההחזרה למצב הקודם, כדאי להפנות את תעבורת זמן הריצה ממרכז הנתונים הזה.

שלבים כלליים

  1. בוחרים מרכז נתונים אחד (ששודרג חלקית או באופן מלא) שרוצים לבצע בו חזרה לגרסה קודמת. הפניית תנועה בזמן ריצה למרכז נתונים אחר שפועל.
  2. מזהים את צומת הזרע במרכז הנתונים ומתחילים עם אחד מצמתי הזרע.
  3. עוצרים את צומת Cassandra, מסירים אותו ומנקים אותו.
  4. מתקינים את הגרסה הישנה יותר של Cassandra בצומת ומגדירים אותה לפי הצורך.
  5. מסירים את ההגדרות הנוספות שהוספתם קודם.
  6. חוזרים על השלבים שלמעלה לכל צומת ראשוני במרכז הנתונים, אחד אחרי השני.
  7. חוזרים על השלבים שלמעלה לכל צומתי Cassandra שנותרו במרכז הנתונים, אחד אחרי השני.
  8. בונים מחדש את הצמתים ממרכז הנתונים הקיים והפונקציונלי, אחד אחרי השני.
  9. מפעילים מחדש את כל רכיבי edge-* במרכז הנתונים שמחוברים ל-Cassandra.
  10. בודקים ומפנים את התנועה חזרה למרכז הנתונים הזה.
  11. חוזרים על השלבים לכל מרכז נתונים, אחד אחרי השני.

שלבים מפורטים

  1. בוחרים מרכז נתונים אחד שבו כל צמתי Cassandra או חלק מהם ישודרגו. הפניית כל התנועה של שרת proxy בזמן ריצה ותנועת ניהול ממרכז הנתונים הזה בזמן שמבצעים החזרה (rollback) של צמתי Cassandra במרכז הנתונים הזה. מוודאים שכל הצמתים של Cassandra נמצאים במצב UN (Up/Normal) כשמריצים את הפקודה 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 בצמתים כדי להבין את המצב הנוכחי של כל האשכול. לדוגמה, התמונה הבאה מציגה מופע של אשכול עם 2 מרכזי נתונים שבו כל הצמתים של 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. בוחרים את צומת הזרע הראשון ב-Cassandra גרסה 4 במרכז הנתונים הזה. תפסיק. 
    # 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 של Edge for Private Cloud 4.52.02. 
    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
  5. יוצרים או עורכים את הקובץ /opt/apigee/customer/application/cassandra.properties.
  6. מוסיפים את התוכן הבא לקובץ. ‫ipOfNode היא כתובת ה-IP של הצומת שמשמשת את Cassandra לתקשורת עם צמתי Cassandra אחרים: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. מוודאים שמשתמש apigee הוא הבעלים של הקובץ ויש לו הרשאת קריאה: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. מתקינים ומגדירים את Cassandra:
    9. # 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
  9. מוודאים שהצומת הופעל. בודקים את הפקודה הבאה בצומת הזה ובצמתים אחרים באשכול. הצומת צריך לדווח שהוא במצב UN (פעיל/רגיל): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. מסירים מהקובץ /opt/apigee/customer/application/cassandra.properties את ההגדרות הנוספות שהוספתם קודם.
  11. חוזרים על שלבים 3 עד 10 בכל אחד מצמתי ה-seed של Cassandra במרכז הנתונים, אחד אחרי השני.
  12. חוזרים על שלבים 3 עד 10 בכל צומתי Cassandra שנותרו במרכז הנתונים, אחד אחרי השני.
  13. בנייה מחדש של כל הצמתים במרכז הנתונים ממרכז נתונים שמופעלת בו גרסה ישנה יותר של Cassandra. מבצעים את השלב הזה בצומת אחד בכל פעם: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    התהליך הזה עשוי להימשך זמן מה. אפשר לשנות את streamingthroughput לפי הצורך. בודקים את nodetool netstats כדי לראות את סטטוס השלמת הפעולה.

  14. (אופציונלי) מריצים את פקודת התיקון בצומת Cassandra אם הנתונים לא נבנים מחדש. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. מפעילים מחדש את כל רכיבי 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
  16. מאמתים את מרכז הנתונים הזה ומפנים אליו את התנועה. מריצים כמה אימותים של תנועת גולשים בזמן ריצה וממשקי API לניהול במרכז הנתונים הזה, ומתחילים להפנות מחדש את תנועת הגולשים של ה-proxy וממשקי ה-API לניהול בחזרה אליו.
  17. חוזרים על השלבים שלמעלה לכל מרכז נתונים שרוצים לבצע בו שחזור.

חזרה לגרסה קודמת של Cassandra באמצעות גיבוי

דרישות מוקדמות

  1. אתם בתהליך של שדרוג Cassandra מגרסה 3.11.X לגרסה 4.0.X ונתקלתם בבעיות במהלך השדרוג.
  2. יש לכם גיבויים של הצומת שאתם מחזירים לגרסה קודמת. הגיבוי בוצע לפני הניסיון לשדרג מגרסה 3.11.X לגרסה 4.0.X.

שלבים

  1. בוחרים צומת אחד שרוצים לבטל את השינויים שבו. אם אתם מבצעים שחזור של כל הצמתים במרכז נתונים באמצעות גיבויים, התחילו עם צמתי ה-seed. אפשר לעיין בקטע 'איך מזהים צמתים ראשוניים' בנספח.

  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 שמופיעות בשורה האחרונה הן צמתי ה-seed. בדוגמה שלמטה, DC-1-IP1,‏ DC-1-IP2,‏ DC-2-IP1 ו-DC-2-IP2 הן כתובות ה-IP של צומתי ה-seed:

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. אחרי שמבצעים Rollback לכל העוקבים והמשקיפים, מבצעים Rollback לצומת הראשי לפי שלבים 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 בהגדרת master-standby:

  • מקדמים את צומת ההמתנה החדש כדי שיהפוך לצומת הראשי של Postgres. גרסת ה-Postgres master החדשה תהיה זהה לגרסה של התקנת 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. מורידים ומריצים את bootstrap של הגרסה הקודמת (של גרסת Apigee שאליה חוזרים) בצומת הישן של הגיבוי. השלבים המדויקים עשויים להשתנות בהתאם לסוג ההתקנה: מבוססת-אינטרנט או אופליין. הפעלת bootstrap של Apigee בגרסה ישנה יותר תגדיר את מאגרי 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. חוזרים על השלב הקודם אחרי ששולחים כמה בקשות API כדי לוודא שהצמתים מסונכרנים.
  20. מוציאים משימוש את ה-Postgres master הישן באמצעות התהליך שמתואר במאמר הוצאה משימוש של צומת 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, ממשקי ה-API לניהול לא יהיו זמינים, מה שעשוי להשפיע על משימות אדמיניסטרטיביות. לפני שממשיכים בתהליך החזרה ל-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. התקנה של גרסה ישנה של LDAP‏ 2.4
    • התקנת גרסה ישנה של 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

    אם ההגדרה היא של שרת יחיד, אפשר להמשיך ישירות לשלב 5ב. כדי להגדיר כמה שרתים, ממשיכים לשלב 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. כדי לבצע Rollback של אחד מהרכיבים עם קוד משותף בצומת, צריך לעצור את כולם, כמו בדוגמה הבאה: 
      /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. כדי לבצע Rollback לרכיב אחר בצומת, מסירים את ההתקנה של הרכיב הזה בלבד, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      כאשר component הוא שם הרכיב.

    4. כדי לבצע Rollback של נתב Edge, צריך למחוק את התוכן של הקובץ /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