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

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

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

  1. חזרה לגרסה ישנה יותר. לדוגמה מ-4.16.09 עד 4.16.05.
  2. חזרה לגרסה קודמת באותה גרסה.

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

מי יכול לבצע את ההחזרה למצב הקודם

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

כברירת מחדל, רכיבי Edge פועלים בתור ה-API של המשתמש. במקרים מסוימים, יכול להיות שרכיבי Edge יופעלו כמשתמשים שונים. לדוגמה, אם הנתב צריך לגשת ליציאות עם הרשאות, כמו יציאות מתחת ל-1,000, צריך להפעיל אותו בתור Root או כמשתמש עם גישה ליציאות האלה. לחלופין, אפשר להפעיל רכיב אחד כמשתמש אחד ורכיב אחר כמשתמש אחר.

אילו רכיבים אפשר להחזיר למצב הקודם

עליך להיות מודע לתנאים הבאים בעת ביצוע החזרה למצב קודם:

  • לחמשת רכיבי Edge שמפורטים בהמשך יש קוד משותף. לכן, כדי לחזור למצב הקודם של כל אחד מחמשת הרכיבים בצומת, עליך להחזיר למצב קודם כל אחד מחמשת הרכיבים שהותקנו בצומת. לדוגמה, אם מותקנים בצומת שרת הניהול, הנתב ומעבד ההודעות, כדי להחזיר את אחד מהם למצב הקודם, תצטרכו להחזיר את שלושתם למצב הקודם.
    חמשת הרכיבים שחולקים את הקוד הם:
    • שרת ניהול
    • נתב
    • מעבד בקשות
    • שרת Qpid
    • שרת Postgres
  • אם העדכון הוא מ-Edge 4.16.01, אין להחזיר את Cassandra לגרסה קודמת. הגרסה הזו של Edge כוללת גרסה מעודכנת של Cassandra. אם רוצים להחזיר רכיבים לגרסה קודמת, משאירים את Cassandra בגרסה 4.16.09.
  • גרסה זו לא מכילה גרסה חדשה של qpidd. לכן, אין צורך להחזיר את qpidd למצב הקודם.

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

הקטע הזה כולל את התהליך של החזרת Edge 4.16.09 לגרסה קודמת. הקטע הזה מחולק לשני חלקים:

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

כדי לבטל את העדכון של Postgres 9.4

כדי לבטל את העדכון של Postgres כשמעדכנים את Postgres בתצורה של מצב המתנה ראשי, עליכם:

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

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

  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-apige-apige-apiges_server stop
  3. אם מותקן Qpid בצומת ההמתנה הישן:
    > /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start

    הערה: בתצורות רבות, צומת ההמתנה הישן יארח רק Postgres, לא Qpid.
  4. מקדמים את צומת ההמתנה החדש בתור המאסטר של Postgres:
    1. מקדמים את צומת המתנה החדש כך שיהיה המאסטר החדש:
      > apigee-service apigee-postgresql מקדם-standby-to-master new_standby_IP

      אם מופיעה בקשה, יש להזין את הסיסמה של Postgres עבור המשתמש 'apigee'. ברירת המחדל היא 'postgres'.
    2. עורכים את קובץ התצורה שבו השתמשתם כדי להתקין את הגרסה הנוכחית של Edge כדי לציין את הפרטים הבאים:
      # כתובת ה-IP של המאסטר החדש:
      PG_MASTER=new_standby_IP
      # כתובת IP של צומת ההמתנה הישנה
      PG_STANDBY=old_standby_IP
    3. מגדירים את המאסטר החדש:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-Replication-on-master -f configFile
  5. יוצרים מחדש את צומת ההמתנה הישן:
    1. עורכים את קובץ התצורה שבו השתמשתם כדי להתקין את הגרסה הנוכחית של Edge כדי לציין את הפרטים הבאים:
      # כתובת ה-IP של המאסטר החדש:
      PG_MASTER=new_standby_IP
      # כתובת IP של צומת ההמתנה הישנה
      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

      אם היא לא פועלת, צריך להפעיל אותה:
      > /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  6. יש לוודא שצומת ההמתנה החדש נוסף על ידי הצגת הקובץ /opt/apigee/apigee-postgresql/conf/pg_hba.conf במאסטר החדש.
  7. כדי להציג את הנתונים הנוכחיים של ניתוח נתונים וקבוצות צרכנים, מריצים את הפקודה הבאה בשרת הניהול:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax

    פקודה זו מחזירה את השם של קבוצת Analytics בשדה name, ואת השם של קבוצת הצרכן בשדה צרכן. הוא גם מחזיר את מזהי ה-UUID של צומתי המאסטר וההמתנה הישנים של Postgres בשדה postgres-server ובשדה datastores. "you com1ef-groups-(com18) (8) (8) (8) (88-CG8) (80GB-CGB-6) (C28) (80) -אמריקנו


















  8. מריצים את פקודת ה-cURL הבאה בצומת המאסטר הישן כדי לקבל את כתובת ה-UUID של המאסטר הישן:
    > curl -u sysAdminEmail:password http://<node_IP>:8084/v1/servers/self


    ה-UUID של הצומת ' [18-16) : "eb4-server בסוף " 9-gres " צריך להופיע בסוף הפלט eb4-server: "eb5-server5 "eb5-server5 " > "19-gres"


    אם שרת Postgres לא פועל, ניתן להריץ את הפקודה הבאה על שרת הניהול כדי לקבוע את ה-UUID:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/servers?pod=analytics

    הפלט של הפקודה הזו מציין את ה-UUID של Postre עבור כתובת ה-IP של כל כתובת IP.
  9. חוזרים על השלב הקודם כדי לקבל את כתובות ה-IP של צומת ההמתנה הישן ושל המאסטר החדש.
  10. מסירים את צומתי המאסטר והמתנה הישנים מקבוצת הצרכנים:
    > curl -u sysAdminEmail:password - X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/dataconsumer-group-001/data

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

    המאפיין datastores של consumer-groups אמור להיות ריק.
  11. מסירים את צומתי המאסטר וההמתנה הישנים מקבוצת analytics:
    > curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=UpostuID property UpostuID availableby-serviceUgruID /servers?uuid=מאסטרUUID

  12. רושמים את צומתי ה-מאסטר והמתנה של PG PG_groups/groupsID analytics-groups-groups-groups/groupid : > curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/ax0/axgroup


  13. מאמתים את קבוצת ניתוח הנתונים:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax

    אתם אמורים לראות את מזהי ה-UUID של צומתי המאסטר וההמתנה החדשים שמופיעים בקבוצת ניתוח הנתונים ובקבוצת הצרכנים.
  14. מפעילים מחדש את שרת הניהול של Edge:
    > /opt/apigee/apigee-service/bin/apigee-service edge-management-server הפעלה מחדש
  15. מפעילים מחדש את כל שרתי Qpid:
    > /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server מחדש
  16. מפעילים מחדש את כל שרתי Postgres:
    > /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server מחדש
  17. מאמתים את סטטוס השכפול על ידי הנפקת הסקריפטים הבאים בשני השרתים. המערכת אמורה להציג תוצאות זהות בשני השרתים כדי להבטיח שהשכפול יתבצע בהצלחה:

    במאסטר החדש, מריצים את:
    > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    מאמתים שהיא המאסטר.

    בצומת ההמתנה הישן:
    > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    מוודאים שמדובר במצב המתנה.
  18. חוזרים על השלב הקודם אחרי שמבצעים כמה בקשות API, כדי לוודא שהצמתים מסונכרנים.
  19. מסירים את המאסטר הישן Postgres באמצעות התהליך של עדכון Apigee Edge לגרסה 4.16.09.

    הערה: אם הצומת הראשי הישן פעל Qpid, אפשר להשאיר את השרת הזה פעיל כדי להפעיל את Qpid. יש לוודא שהוא פועל. אם לא, צריך להפעיל אותו:
    > /opt/apigee/apigee-service/bin/apigee-service edge-management-server start

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

צריך לבטל Qpid מהמאסטר הישן ולהתקין Qpid במאסטר החדש

כדי להסיר את Qpid מהמאסטר הישן ולהתקין אותו במאסטר החדש:

  1. מריצים את הפקודה הבאה בכל מעבדי ההודעות כדי לחסום את הגישה ליציאה Qpid 5672 מהמאסטר הישן:
    > iptables -A OUTPUT -p tcp -d 10.233.147.20 --dport 5672 -j DROP
  2. מריצים את הפקודה הבאה כדי לוודא שתור ההודעות של Qpid ריק. אי אפשר להסיר את Qpid לפני העיבוד של כל ההודעות הממתינות:
    > qpid-stat -q

    הפקודה הזו מציגה טבלה שמכילה ספירה של msg, msgIn ו-msgOut. כל ההודעות יעובדו כאשר msg=0, ו-msgIn=msgOut.
  3. קביעת ה-UUID של שרת ה-Qpid במאסטר הישן על ידי הרצת הפקודה הבאה במאסטר הישן. יש לשמור את המידע הזה למועד מאוחר יותר בתהליך:
    > curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self
  4. עצירת ה-Qpid במאסטר הישן:
    > /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
    > /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
  5. הסרה של שרת Qpid:
    > /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server Remove
    > /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd הסרה
  6. מסירים את שרת ה-Qpid הישן מהקבוצות analytics/consumer_groups. (analytics-groups/consumer_groups ) (החיוב של קבוצת צרכנים) > curl -u sysAdminEmail:password -X DELETE -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-00


  7. מסירים את שרת ה-Qpid הישן מ-Zookeeper:
    > curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/qpid_UUID
  8. מתקינים את Qpid במאסטר החדש:
    > /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
  9. קביעת ה-UUID של שרת ה-Qpid במאסטר החדש על ידי הרצת הפקודה הבאה במאסטר החדש. יש לשמור את המידע הזה למועד מאוחר יותר בתהליך:
    > curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self
  10. רושמים את שרת ה-Qpid החדש Qpid ב-analytics/consumer_groups "text-consumer-groups.


  11. מפעילים מחדש את כל מעבדים ההודעות:
    > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor
  12. כדי לבדוק אם נוצרו תורי תורים, מריצים את הפקודה הבאה בשרת ה-Qpid החדש:
    > qpid-stat -q

    מוודאים שההודעות msg, msgIn ו-msgOut מתעדכנות בזמן ששרת ה-Qpid מעבד הודעות.

כדי להחזיר רכיבים נפרדים לגרסה 4.16.09

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

  • כדי לחזור לגרסה 4.16.05, צריך להוריד את shoestrap_4.16.05.sh
  • כדי לחזור לגרסה 4.16.01, downlaod shoestrap.sh

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

  1. עוצרים את הרכיב כדי להחזיר אותו למצב הקודם:
    1. אם מחזירים לגרסה הקודמת אחד מהרכיבים הבאים בצומת, צריך להפסיק את כולם: שרת ניהול, נתב, מעבד הודעות, Qpid Server או שרת Postgres:
      • > apigee-service end-management-management-server
      • > apigee-service end-router stop
      • > apigee-service edge-message-processor
      • > apigee-service edge-qpid-server stop
      • > apigee-service edge-postgres-server stop
    2. אם מחזירים לגרסה הקודמת רכיב אחר בצומת, צריך להפסיק רק את הרכיב הזה:
      • > עצירת שירות API comp
  2. אם רוצים להחזיר את המונטיזציה, צריך להסיר אותה מכל הצמתים של שרת הניהול ומעבד ההודעות:
    > הסרה של שער apigee-service end-mint-gateway
  3. מסירים את הרכיב כדי לחזור למצב קודם בצומת:
    1. אם מחזירים לגרסה הקודמת חלק מהרכיבים הבאים בצומת, צריך להסיר את כולם: שרת ניהול, נתב, מעבד הודעות, Qpid Server או Postgres Server:
      > הסרה של שער קצה עבור שירות apigee-service
    2. אם מחזירים לגרסה הקודמת רכיב אחר בצומת, צריך להסיר רק את הרכיב הזה:
      > הסרת apigee-service comp
  4. אם רוצים להחזיר את הנתב למצב הקודם, צריך למחוק את התוכן של /opt/nginx/conf.d:
    > cd /opt/nginx/conf.d
    > rm -rf *
  5. כדי להחזיר את הרכיב לגרסה קודמת:
    1. מסירים את הגרסה 4.16.09 של apigee-setup:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-setup הסרה
    2. מורידים את הקובץ shoestrap.sh לגרסה 4.16.01 או 4.16.05:
      לגרסה 4.16.01:
      > curl https://software.apigee.com/shoestrap.sh -o /tmp/shoestrap.sh

      עבור 4.16.05shoes.appstrapapi.
    3. מתקינים את כלי העזר ויחסי תלות של שירות apigee-service 4.16.01 או 4.16.05:
      > sudo bash /tmp/shoestrap.sh apigeeuser=uName apigeepassword=pWord

      כאשר uName ו-uName התקבלו מה-API ו-pWorde. אם לא כוללים את pWord, תופיע בקשה להזין אותו.
    4. מתקינים את הגרסה 4.16.01 או 4.16.05 של apigee-setup:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. מתקינים את הגרסה 4.16.01 או 4.16.05 של הרכיב:
      > > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

      כאשר comp הוא הרכיב להתקנה ו-configFile הוא קובץ 15 או 6.0 קובץ 15.1 שלכם.
  6. כדי להחזיר את הרכיב לגרסה קודמת ספציפית של גרסה 4.16.05:
    1. מורידים את גרסת הרכיב הספציפית:
      > /<instal_dir>/apigee/apigee-service/bin/apigee-service comp-version התקנה

      כאשר comp-version הוא הרכיב והגרסה שיש להתקין. לדוגמה:
      > /<instal_dir>/apigee/apigee-service/bin/apigee-service edge-ui-4.16.05-0.0.3649 install

      אם משתמשים במאגר אונליין של Apigee, אפשר לקבוע את גרסאות הרכיבים הזמינות באמצעות הפקודה הבאה
      > y showum>


    2. משתמשים ב-apigee-setup כדי להתקין את הרכיב:
      > /<install_dir>/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

      לדוגמה:
      > /<install_dir>/apigee/apigee-setup-puigee/apigee-setup-bin/setup

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