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

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

אפשר להחזיר את Edge 4.54.00 לכל אחת מגרסאות ההפצה הראשיות הבאות:

  • גרסה 4.53.00
  • גרסה 4.53.01

מידע נוסף זמין במאמר תהליך פרסום גרסאות של Apigee Edge.

סדר החזרה למצב קודם

צריך לבצע את החזרה לגרסה הקודמת של הרכיבים בסדר הפוך לסדר שבו הם שודרגו. סדר הפעולות הכללי האופייני להחזרה לגרסה קודמת ב-Private Cloud 4.54.00 ייראה כך:

  • החזרה למצב קודם של Cassandra ו-Zookeeper.
  • מבטלים את השינויים ב-Qpid, ברכיבים אחרים שקשורים לניתוח נתונים וב-Postgres.
  • חזרה לממשק המשתמש הקודם
  • חזרה למצב קודם של LDAP.
  • החזרה של שרת הניהול לגרסה קודמת.
  • החזרה לגרסה קודמת של נתבים ומעבדי הודעות.

לדוגמה, נניח ששדרגתם את כל הנתבים ומעבדי הבקשות, את כל שרתי הניהול, את LDAP וכמה צומתי ממשק משתמש לגרסה 4.54.00 מגרסה 4.53.00 (או) 4.53.01, ואתם רוצים לחזור לגרסה הקודמת. במקרה כזה, תצטרכו:

  • חזרה לגרסה הקודמת של הצמתים המשודרגים של ממשק המשתמש
  • חזרה למצב הקודם של צומתי ה-LDAP
  • החזרה של צמתים בשרת הניהול לגרסה קודמת, אחד אחרי השני
  • החזרה של כל ה-RMP למצב הקודם, אחד אחרי השני

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

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

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

חזרה לגרסה קודמת של Cassandra

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

תרחישי החזרה למצב קודם

בטבלה הבאה מפורטות שיטות החזרה לגרסה קודמת שבהן אפשר להשתמש:

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

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

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

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

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

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

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

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

השלבים העיקריים

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

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

  1. בוחרים מרכז נתונים אחד שבו משדרגים את כל צומתי Cassandra או חלק מהם. צריך להפנות את כל תנועת ה-proxy בזמן הריצה ואת תנועת הניהול ממרכז הנתונים הזה בזמן שצמתי 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:
    5.0.8: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    4.0.13: [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. זיהוי צומתי ה-seed במרכז הנתונים: עיינו בקטע איך מזהים צומתי seed בנספח. מבצעים את השלבים הבאים באחד מצמתי הזרע:
  3. מפסיקים את הפעולה, מסירים את ההתקנה ומנקים את הנתונים מהצומת של Cassandra. בוחרים את צומת ה-seed הראשון ב-Cassandra גרסה 5 במרכז הנתונים הזה. תפסיק. 
    # 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.53.00/4.53.01. 
    5. # Download bootstrap of 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap of 4.53.00
sudo bash /tmp/bootstrap_4.53.00.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 4.0.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. מאמתים את מרכז הנתונים ומפנים אליו בחזרה את התנועה. מריצים כמה אימותים של תעבורת נתונים בזמן ריצה ושל Management API לניהול במרכז הנתונים הזה, ומתחילים לנתב מחדש את תעבורת הנתונים של שרת ה-proxy ושל Management API לניהול בחזרה אליו.
  17. חוזרים על השלבים שלמעלה לכל מרכז נתונים שרוצים להחזיר לגרסה קודמת.

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

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

  1. אתם משדרגים את Cassandra מגרסה 4.0.X לגרסה 5.0.X ונתקלתם בבעיות במהלך השדרוג.
  2. יש לכם גיבויים של הצומת שאתם מחזירים לגרסה קודמת. הגיבוי בוצע לפני הניסיון לשדרג מגרסה 4.0.X לגרסה 5.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.53.00/4.53.01:
      • # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.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 4.0.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

רולבק

אם צריך לחזור לגרסה הקודמת:

  1. קודם מבצעים את שלבי החזרה למצב הקודם בצופים ובעוקבים. כדי לבחור משקיפים ועוקבים, עיינו בקטע זיהוי מנהיג, עוקבים ומשקיפים.
  2. מורידים ומפעילים את ה-bootstrap של הגרסה שאליה חוזרים – 4.53.00 או 4.53.01. התהליך עשוי להשתנות בהתאם לחיבור של הצומת לאינטרנט החיצוני או אם אתם מבצעים התקנה אופליין.
  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. אחרי שכל הצמתים חזרו לגרסה הקודמת, בודקים את תקינות האשכול ומוודאים שיש צומת מוביל באשכול.

שחזור הגיבוי

איך משחזרים מהגיבוי

חזרה לגרסה קודמת של Qpid

כדי לחזור לגרסת פיצ'רים קודמת, צריך להוריד את קובץ ה-bootstrap.sh של הגרסה שאליה רוצים לחזור. כדי לחזור לגרסה 4.53.00/4.53.01, צריך להוריד את bootstrap_4.53.00.sh.

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

  1. עוצרים את ה-Qpid broker הקיים: 
    apigee-service apigee-qpidd stop
  2. חסימת תנועה נכנסת ביציאת הברוקר 5672 מכל מעבדי ההודעות באמצעות הפעלת חומת אש. אפשר להחיל את חומת האש הזו ברמת המכונה של צומת Qpid או ברכיב חיצוני אחר של חומת אש או רשת.

    מומלץ לבצע את אותו שלב לכל כתובות ה-IP של מעבדי הבקשות. לדוגמה, כדי להשליך בקשות שמגיעות מכתובות IP של מעבד הודעות לצומת Qpid ביציאה 5672 באמצעות IPTables, אפשר להשתמש בפקודה כזו:

    iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
  3. מפעילים שוב את ה-broker של Qpid כדי לרוקן את ההודעות הקיימות, אם יש כאלה: 
    apigee-service apigee-qpidd start
  4. מוודאים שהתורים הקיימים ריקים. כדי לבדוק, מתחברים לפורטל הניהול של Qpid: 
    http://QPID_NODE_IP:8090
  5. אחרי שמוודאים שהתורים התרוקנו, מפסיקים את Qpid ומסירים אותו: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall
  6. מוחקים את ספריית הנתונים של Qpid: 
    rm -r APIGEE_ROOT/data/apigee-qpidd
  7. מתקינים מחדש את Qpid broker: 
    /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
  8. אחרי שמתקינים מחדש את Qpid broker, מסירים את הגדרות חומת האש ומציגים את ההגדרות הקיימות באמצעות הפקודות הבאות: 
    iptables -F
iptables -L

חזרה לגרסה קודמת של Postgres

כדי לשדרג לאחור מגרסה 4.54.00 לגרסה 4.53.00/4.53.01, צריך להחזיר את עדכון Postgres לגרסה קודמת בנוסף לרכיבי Edge.

כדי לבטל את העדכון של Postgres כשמעדכנים את Postgres בהגדרה של master-standby:

  • מקפיצים את צומת ההמתנה החדש כדי שיהפוך למאסטר של Postgres. הגרסה של מאסטר Postgres החדש תהיה זהה לגרסה של התקנת Edge הקודמת.
  • מגדירים את צומת הגיבוי הישן כצומת הגיבוי של המאסטר החדש. הצומת הישן במצב המתנה יהיה באותה גרסה כמו ההתקנה הקודמת של Edge.
  • רושמים את הצמתים החדשים של המאסטר וההמתנה בקבוצות של ניתוח הנתונים והצרכנים.

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

לפני שמתחילים

לפני שמחזירים את Postgres מגרסה 18 לגרסה 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
apigee-service edge-analytics 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 Management Server: 
    /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:

    אפשרות נוספת היא להסיר את Qpid מהמאסטר הישן ולהתקין את Qpid בצומת המאסטר החדש. אחרי הסרת ההתקנה של Qpid, אפשר להוציא משימוש את צומת המאסטר הישן.

חזרה לממשק המשתמש הקודם של Edge

גרסה 4.54.00 של Apigee Edge for Private Cloud מחליפה את ממשק המשתמש הקלאסי (edge-ui) בממשק המשתמש החדש של Edge‏ (edge-management-ui). בגלל השינויים ברכיב ממשק המשתמש בגרסה 4.54.00, כדי לחזור לגרסה 4.53.00 או לגרסה 4.53.01 צריך להסיר את edge-management-ui ולהתקין מחדש את פרופיל ממשק המשתמש הקודם:

  • ממשק משתמש קלאסי (edge-ui): מתקינים מחדש את פרופיל ui.
  • ממשק משתמש חדש של Edge‏ (edge-ui ו-edge-management-ui): מתקינים מחדש את הפרופילים ui ו-ue בצמתים המתאימים.

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

  1. כדי להחזיר את הגרסה הקודמת, צריך להפסיק את השימוש בממשק המשתמש החדש של New Edge בגרסה 4.54.00, להסיר אותה ולהתקין את הגרסה הקודמת:
    1. עוצרים ומסירים את ממשק המשתמש החדש של Edge בגרסה 4.54.00 (edge-management-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui uninstall
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui-static uninstall
    2. מריצים את קובץ ה-bootstrap עבור Apigee Edge for Private Cloud 4.53.00/4.53.01: 
      # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    3. חזרה לגרסה קודמת של apigee-setup מגרסה 4.54.00: 
      # Uninstall apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

# Install apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  2. שחזור הגדרות ממשק המשתמש של גרסה 4.53.00 או 4.53.01:
    • אם גיביתם את קובץ התצורה השקט מההתקנה של גרסה 4.53.00 או 4.53.01, השתמשו בקובץ הגיבוי הזה להליך החזרה לגרסה קודמת. אחרת, בקובץ התצורה השקט של גרסה 4.54.00, משחזרים או מבטלים את הסימון כהערה של מאפייני ממשק המשתמש של גרסה 4.53.00 או 4.53.01 שהוסרו או סומנו כהערה במהלך השדרוג. למידע נוסף, עיינו בקטע בנושא שדרוג ממשק המשתמש.
    • אם הקובץ /opt/apigee/customer/application/ui.properties נמחק במהלך השדרוג, צריך לשחזר אותו מספריית הגיבוי: 
      cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
  3. מתקינים מחדש ומגדירים את הגרסה הקודמת של ממשק המשתמש:
    • חזרה לממשק המשתמש הקלאסי (edge-ui):
      1. התקנה והגדרה של ממשק משתמש קלאסי (ל-Basic Auth, לא נדרשים שלבים נוספים): 
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
      2. אם ה-SSO מופעל, מגדירים את ה-SSO בממשק המשתמש הקלאסי (קודם צריך לוודא ש-apigee-sso פועל): 
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
    • חזרה לגרסה 4.53.00 או 4.53.01 של ממשק המשתמש החדש של Edge (edge-management-ui ו-Shoehorn edge-ui):
      1. מוודאים שהערך EDGEUI_ENABLE_UNIFIED_UI=y מוגדר בקובץ התצורה השקט, ואז מתקינים ומגדירים את הפרופילים ui ו-ue: 
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
      2. אם SSO מופעל, צריך להגדיר SSO בשני רכיבי ממשק המשתמש (חשוב לוודא ש-apigee-sso פועל קודם): 
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile
  4. בודקים את הסטטוס והגרסה של ממשק המשתמש שהוחזר לגרסה קודמת:
    • בממשק הקלאסי (edge-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-ui version
    • בממשק המשתמש החדש של Edge (edge-management-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui version

חזרה לגרסה קודמת של OpenLDAP

בקטע הזה מפורטות הוראות להחזרה של Symas OpenLDAP 2.6.10 ב-Edge for Private Cloud 4.54.00 ל-OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) או ל-Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01). צריך לבצע את החזרה לגרסה הקודמת בכל אשכול ה-LDAP באמצעות גיבוי LDAP תקין מלפני השדרוג.

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

לפני שמתחילים

  • חוסר תאימות של הגיבוי: צריך להשתמש בגיבוי שנוצר לפני השדרוג מ-OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) או מ-Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01) באמצעות apigee-service apigee-openldap backup לפני הניסיון לשדרג. גיבויים שבוצעו אחרי השדרוג לא תואמים ואי אפשר להשתמש בהם.
  • זמן השבתה של Management API: במהלך החזרה לגרסה הקודמת של LDAP, ממשקי Management API לא יהיו זמינים, וזה עלול להשפיע על משימות הניהול. לפני שמבצעים את החזרה לגרסה קודמת של LDAP, צריך לסגור את כל המכונות של edge-management-server ו-edge-ui.
  • סיכון לאובדן נתונים: אם ממשיכים בלי גיבוי תקין ותואם, יש סיכון לאובדן נתונים בלתי הפיך.
  • גיבוי תקין: נדרש גיבוי LDAP תקין לפני השדרוג.
  • גיבוי של קובצי silent.conf: שומרים גיבויים של קובצי silent.conf מהגרסה הקודמת ומהגרסה הנוכחית כדי למנוע בלבול בהגדרות במהלך השדרוג והחזרה לגרסה קודמת.
  • רצף החזרה לאחור: לפני שמחזירים לאחור את OpenLDAP, צריך להשלים את תהליכי ההחזרה לאחור של Cassandra, ‏ ZooKeeper, ‏ Qpid, ‏ PostgreSQL, ‏ apigee-sso וממשק המשתמש של Edge.

תהליך החזרה למצב קודם

  1. השבתה של שרת הניהול וממשק המשתמש: צריך להשבית את כל המופעים של edge-management-server ושל edge-ui לפני שממשיכים בשחזור של LDAP: 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. תיעוד של מספר רשומות ה-LDAP הנוכחי (לפני עצירת ה-LDAP): כדי לקבל את המספר הכולל של הרשומות מכל שרתי ה-LDAP, מחליפים את YOUR_PASSWORD בסיסמה הנוכחית של מנהל ה-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.46 או 2.6.7:
    • התקנת גרסה ישנה של LDAP: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • אימות גרסת LDAP: 
      source ~/.bash_profile
ldapsearch -VV

# Expected output if rolled back to 4.53.00:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46

# Expected output if rolled back to 4.53.01:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7
    • חוזרים על שלבי המשנה הקודמים בשלב 4 בכל צומת LDAP, אחד בכל פעם.
  5. ניקוי נתונים שיוריים: בכל שרתי ה-LDAP, אחד בכל פעם, מפסיקים את השירות שהותקן לאחרונה ומנקים את ספריית הנתונים שלו כדי להתכונן לשחזור מהגיבוי: 
    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. שחזור נתוני LDAP: בהגדרה של שרת יחיד, ממשיכים ישירות לשלב 6ב. אם אתם מגדירים כמה שרתים, המשיכו לשלב 6א.
    1. זיהוי שרת ה-LDAP הפעיל: לפני שמשחזרים נתוני LDAP, צריך לזהות את השרת הפעיל (הספק) על ידי הפעלת הפקודה הבאה: 
      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
    2. משחזרים את נתוני ה-LDAP (לפני השחזור, מוודאים ששלב 5 הושלם בכל השרתים):
      • בשרת LDAP היחיד או הפעיל (שנקבע בשלב 6א), עוברים לספריית הגיבוי ומשחזרים את הגיבוי שנוצר לפני השדרוג (לדוגמה, 2025.07.28,13.59.00, או משמיטים את חותמת הזמן אם הגיבוי שנוצר לפני השדרוג הוא הגיבוי האחרון בספרייה): 
        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, ומחליפים את YOUR_PASSWORD בסיסמה הנוכחית של מנהל ה-LDAP. מספר הרשומות צריך להיות זהה בכל השרתים, וצריך להיות זהה למספר שרשמתם בשלב 2: 
      # 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
    • אחרי שמוודאים שהנתונים נכונים ועקביים, מפעילים את edge-management-server, את edge-ui וכל רכיב תלוי אחר בהתאם לנוהל הרגיל של הארגון.

החזרה לגרסה קודמת של רכיבי Edge

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

הרכיבים הבאים של Edge חולקים קוד משותף. לכן, כדי להחזיר לגרסה קודמת כל אחד מהרכיבים האלה בצומת, צריך להחזיר לגרסה קודמת את כל הרכיבים האלה שנמצאים בצומת:

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

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

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

  1. מורידים את קובץ ה-bootstrap.sh של הגרסה שאליה רוצים לחזור:

    • כדי לחזור לגרסה 4.53.00/4.53.01, מורידים את bootstrap_4.53.00.sh/bootstrap_4.53.01.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.30.x
    3. כדי להחזיר לגרסה קודמת רכיב אחר בצומת, מסירים רק את הרכיב הזה, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

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

    4. כדי לבטל את השינויים בנתב Edge, צריך למחוק את התוכן של הקובץ /opt/nginx/conf.d בנוסף להסרת ההתקנה של קבוצת הרכיבים edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. מסירים את גרסה 4.54.00 של apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. מתקינים את גרסה 4.53.00 של כלי השירות apigee-service ואת יחסי התלות שלה. בדוגמה הבאה מתקינים את גרסה 4.53.00 של apigee-service: 
    sudo bash /tmp/bootstrap_4.53.00.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