דף זה תורגם על ידי Cloud Translation API.

חזרה למצב קודם של Apigee Edge 4.52.02

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

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

גרסה 4.52.01
גרסה 4.52.00
גרסה 4.51.00

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

חזרה לגרסה	שיקולים מיוחדים לגבי תוכנות
4.52.01	Cassandra
4.52.00	Zookeeper, ‏ Cassandra, ‏ Qpid
4.51.00	Zookeeper, ‏ Postgres, ‏ Cassandra, ‏ Qpid

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

חזרה לגרסה קודמת (עיקרית או משנית). לדוגמה, מ-4.52.02 ל-4.52.00.
חזרה לגרסה קודמת של תיקון באותה גרסה. לדוגמה, מ-4.52.00.02 ל-4.52.00.01.

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

סדר הביטול לאחור

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

סדר אופרטיבי כללי לדחיפה לאחור ב-Private Cloud 4.52.02 ייראה כך:

מרכז נתונים יחיד

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

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

כמה מרכזי נתונים

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

החזרה לאחור של Qpid ורכיבים אחרים שקשורים לניתוח נתונים בכל שרתי ה-DC.
חסימה של התנועה במרכז הנתונים הראשון והפניית התנועה למרכזי נתונים אחרים.
החזרת הנתב ומעבד ההודעות למצב הקודם במרכז הנתונים הראשון.
מבצעים ביטול טרנזקציה (rollback) של Cassandra במרכז הנתונים הראשון.
שרת ניהול החזרה לאחור במרכז הנתונים הראשון.
מבטלים את החסימה של התנועה במרכז הנתונים הראשון ופועלים לפי שלבים 2 עד 6 עד שהחזרה לאחור של צמתים בסביבת זמן הריצה, של Cassandra ושל שרת הניהול תתבצע במרכז הנתונים האחרון.
ביטול השינויים ב-Postgres, ב-Zookeeper וב-LDAP בכל שרתי ה-DC.

כדי להבין את המשמעות, נניח שדרגתם את כל אשכול Cassandra, את כל שרתי הניהול ואת כמה מעבדי הודעות בסביבת זמן ריצה (RMP) מגרסה 4.52.01 לגרסה 4.52.02, ואתם צריכים לבצע חזרה לאחור. במקרה כזה, צריך לבצע את החזרה לאחור באופן הבא:

חסימת התנועה למרכז הנתונים הראשון (data center) וניתוב מחדש של התנועה למרכזי הנתונים הפעילים האחרים כדי להבטיח את המשכיות השירות.
חזרה לאחור של נתבים ומעבדי הודעות במרכז הנתונים הראשון.
חזרה לאחור (Rollback) של Cassandra במרכז הנתונים הראשון על ידי שחזור מגיבוי או מ-snapshot של מכונה וירטואלית.
משיבים את שרת הניהול לאחור במרכז הנתונים הראשון.
ביטול החסימה של התנועה למרכז הנתונים הראשון.
חוזרים על שלבים 1 עד 5 בכל מרכז נתונים שנותר עד שכל הצמתים של Runtime,‏ Cassandra ושרתי הניהול יימחקו.

מי יכול לבצע ביטול טרנזקציה

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

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

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

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

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

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

ביטול שינויים ב-Cassandra

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

שיטות לביטול שינויים

תרחישים של ביטול שינויים

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

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

תרחיש	אסטרטגיית ביטול השינויים
מרכז נתונים יחיד, חלק מהצומתים של Cassandra שודרגו	שחזור גיבוי
מרכז נתונים יחיד, כל צמתים של Cassandra שודרגו	שחזור גיבוי
מרכז נתונים יחיד, כל הצמתים (Cassandra, ‏ Management server וצמתים של Runtime) שודרגו	החזרה לאחור של צמתים בסביבת זמן ריצה שחזור של גיבוי Cassandra החזרה לאחור של שינויים בניהול
כמה מרכזי נתונים, חלק/כל צמתים של Cassandra במרכז הנתונים הראשון שודרגו	יצירת מרכז נתונים מחדש מאחד קיים
מספר מרכזי נתונים, כל צמתים של Cassandra, שרת ניהול וצמתים של Runtime במרכז הנתונים הראשון ששודרג	החזרה לאחור של צמתים בסביבת זמן ריצה שחזור של יצירת מחדש של Cassandra החזרה לאחור של שינויים בניהול צריך לבצע את הפעולה הזו במרכז נתונים אחד בכל פעם.
כמה מרכזי נתונים, חלק או כל צמתים של Cassandra במרכז הנתונים האחרון משודרגים	החזרה לאחור של מרכז הנתונים האחרון באמצעות גיבוי מבצעים חזרה לאחור (rollback) של שאר מרכזי הנתונים באמצעות גיבוי או יצירה מחדש, מרכז נתונים אחד בכל פעם.
מספר מרכזי נתונים, כל צמתים של Cassandra, שרת ניהול וצמתים של Runtime ששודרגו בכל מרכזי הנתונים	החזרה לאחור של צמתים בסביבת זמן ריצה שחזור של גיבוי של Cassandra החזרה לאחור של שינויים בניהול צריך לבצע את הפעולה הזו מרכז נתונים אחד בכל פעם.

באופן כללי, כדאי לשקול את הדברים הבאים כשמבטלים את השינויים ב-Cassandra:

החזרה לאחור של רכיבי זמן ריצה או רכיבי ניהול
אם צריך לבצע חזרה לגרסה קודמת של Edge Private Cloud ברכיבים כמו Edge Management Server או Edge Message Processor בכל מרכז נתונים (DC), חשוב לוודא שגם Cassandra תוחזר לגרסה הקודמת באותו מרכז נתונים ספציפי באותו זמן. הפעולה הזו נחוצה כדי למנוע כשלים בניהול ובתנועה בסביבת זמן הריצה.
החזרה לאחור באמצעות גיבויים
גיבויים שנוצרו מ-Cassandra 3.11.x לא תואמים לגיבויים שנוצרו מ-Cassandra 2.1.x. כדי לאפשר חזרה לאחור באמצעות שחזור גיבוי, צריך לוודא שגיבויים של Cassandra 2.1.x נוצרו לפני ביצוע השדרוג.
ביצוע בידוד של מרכז הנתונים לצורך ביטול השינויים
כדי למנוע זמן השבתה, חשוב לוודא שהתנועה מנותבת למרכזי נתונים שפועלים באופן מלא, ושהיא חסומה מפני מרכז הנתונים שבו מתבצע החזרה לאחור.

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

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

אתם מפעילים אשכול של Edge for Private Cloud בגרסה 4.51.00, 4.52.00 או 4.52.01 במספר מרכזי נתונים
אתם בתהליך שדרוג של Cassandra מגרסה 2.1.X לגרסה 3.11.X ונתקלת בבעיות במהלך השדרוג
יש לכם לפחות מרכז נתונים אחד שפועל באופן מלא באשכול, שעדיין פועל בגרסה הישנה יותר של Cassandra‏ (Cassandra 2.1.X)

שלבים ברמה גבוהה

בוחרים מרכז נתונים אחד (ששדרגתם באופן חלקי או מלא) שרוצים לבצע בו חזרה לאחור. להפנות את כל תעבורת הנתונים של האפליקציות ממרכז הנתונים הזה למרכז נתונים אחר שפועל באופן מלא.
אם שדרגתם את Router and Message Processor, צריך לבצע חזרה לאחור לכל הצמתים של Router and Message Processor במרכז הנתונים, אחד אחרי השני.
עוצרים את Cassandra בצומת אחד, מסירים אותה ומנקים את כל הנתונים המשויכים.
מתקינים את ה-bootstrap של הגרסה הקודמת ומגדירים את Cassandra בגרסה 2.1.x בצומת שניקוי.
צריך לבנות מחדש את הצומת ממרכז הנתונים הפונקציונלי הקיים שבו עדיין פועלת Cassandra 2.1.x.
מבצעים את שלבים 3 עד 5 בכל צומת Cassandra שנותר במרכז הנתונים, צומת אחד בכל פעם.
מריצים מחדש את ההגדרה של שרת הניהול במרכז הנתונים.
מבצעים בדיקות כדי לאמת את החזרה לאחור. אחרי האימות, מפנים את תעבורת הנתונים של האפליקציה חזרה למרכז הנתונים ששוחזר.
חוזרים על השלבים שלמעלה בשאר מרכזי הנתונים שצריך לבצע בהם חזרה לאחור, אחד אחרי השני.

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

מתחילים מהצומת שרוצים לבצע בו חזרה לאחור

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

מפסיקים את Cassandra בצומת:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

מסירים את תוכנת Cassandra מהצומת:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

מסירים את ספריית הנתונים מהצומת:
```
rm -rf /opt/apigee/data/apigee-cassandra
```
מורידים ומפעילים את קובץ ה-bootstrap של הגרסה הישנה של Edge for Private Cloud שאליה רוצים לחזור אחורה:

דוגמה: כדי לבצע חזרה לגרסה 4.52.01

מורידים את קובץ ה-bootstrap של גרסת 4.52.01:

curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’

מריצים את ה-bootstrap של גרסת 4.52.01:

sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

מתקינים את תוכנת Cassandra בצומת:
```
apigee-service apigee-cassandra install
```

מוסיפים את הנכס הבא לקובץ /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh.

JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>"

דוגמה:

JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=10.0.0.1"

מגדירים את Cassandra בצומת:
```
/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
```
הערה: אם תהליך ההגדרה של Cassandra נכשל, עורכים את הקובץ /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh ומסירים את השורה שמכילה את הטקסט: JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>" אחרי ביצוע השינוי הזה, מריצים מחדש את הסקריפט setup.sh שלמעלה כדי לנסות שוב את ההגדרה.
אחרי ש-Cassandra פועלת, מסירים את ה-CWC שלמעלה מהקובץ הבא:קובץ /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh.
הפעלה מחדש של צומת Cassandra
```
apigee-service apigee-cassandra restart
```

מריצים את ה-rebuild בצומת על ידי ציון השם של מרכז הנתונים הפונקציונלי:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h <node-IP> <functional-dc>

דוגמה:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h 10.0.0.1 dc-2

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

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

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

החזרת שרת הניהול לגרסה ישנה יותר

עוצרים את שרת הניהול:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server 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

מורידים ומריצים את ה-bootstrap של הגרסה הישנה יותר. לדוגמה, כדי להוריד ולהריץ את ה-bootstrap של גרסה 4.52.01:

curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’

sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

הגדרת שרת הניהול

מריצים את ההגדרה של צומת אחד של שרת ניהול:
```
/opt/apigee/apigee-setup/bin/setup.sh -p mt -f configFile
```
אחרי שתבצעו את השלבים שלמעלה, עליכם להפנות מחדש את התנועה למרכז הנתונים שבו בוצעה ההחזרה לאחור.

אופטימיזציה אחרי בנייה מחדש

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

דוגמה: נניח שיש לכם שישה צמתים של Cassandra במרכז הנתונים המקומי. כברירת מחדל, גורם השכפול של Apigee הוא שלוש, כך שכל צומת מכיל 50% מהנתונים. במקרה כזה, אפשר לבנות מחדש את הצמתים 1 ו-4 לפי התהליך שמתואר למעלה. בצמתים 2, 3, 5 ו-6, פועלים לפי השלבים הבאים כדי לשחזר את הגיבוי ולהריץ תיקון.

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

משחזרים את הגיבוי שצילמתם בצומת הזה (הערה: סביר להניח שהגיבוי הזה יכלול נתונים לא עדכניים, כי הוא בוצע לפני תחילת השדרוג של Cassandra):
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
```
אם יש לכם קובץ snapshot של המכונה הווירטואלית של הצומת, אתם יכולים לשחזר את קובץ ה-snapshot במקום לשחזר את הגיבוי של Cassandra.
אחרי שחזור הגיבוי, מפעילים את שירות Cassandra בצומת:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
```
מבצעים תיקון בצומת כדי שניתן יהיה להעביר את הנתונים העדכניים ביותר בסטרימינג ממרכז נתונים קיים:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -dc <local-dc-name>
```
דוגמה:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h 10.0.0.1 repair -dc dc-1
```
חוזרים על כל השלבים שלמעלה שמפורטים בשלב 2 בכל צומת שרוצים לתקן.

ביטול השינויים ב-Cassandra באמצעות קובץ גיבוי או קובץ snapshot של מכונה וירטואלית

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

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

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

שלבים ברמה גבוהה

בוחרים מרכז נתונים (ששדרגתם באופן חלקי או מלא) כדי לבצע את החזרה לאחור. להפנות את כל התנועה בסביבת זמן הריצה ממרכז הנתונים הזה למרכז נתונים אחר שפועל באופן מלא.
אם השדרוג של הנתב ומעבד ההודעות בוצע, צריך לבצע חזרה לאחור של כל צמתים של הנתב ומעבד ההודעות במרכז הנתונים, אחד אחרי השני
מפסיקים את Cassandra בצומת אחד, מסירים אותה ומנקים את כל הנתונים המשויכים.
מתקינים את גרסת ה-bootstrap הקודמת ומגדירים את Cassandra בגרסה 2.1.x בצומת שניקוי.
עוצרים את צומת Cassandra ומנקים את כל הנתונים המשויכים.
משחזרים את צומת Cassandra מהגיבוי שנוצר לפני השדרוג.
חוזרים על שלבים 3 עד 6 לכל אחד משאר צמתים של Cassandra במרכז הנתונים, צומת אחד בכל פעם.
מריצים מחדש את ההגדרה של שרת הניהול במרכז הנתונים.
מבצעים בדיקות כדי לאמת את החזרה לאחור. אחרי האימות, מפנים את תעבורת הנתונים בסביבת זמן הריצה חזרה למרכז הנתונים ששוחזר.
חוזרים על השלבים שלמעלה בשאר מרכזי הנתונים שצריך לבצע בהם חזרה לאחור, אחד אחרי השני.
(אופציונלי) מריצים את פקודת התיקון בכל צמתים של Cassandra בכל מרכזי הנתונים, אם יש חוסר עקביות בנתונים ביניהם.

שלבים מפורטים לשחזור גרסת קודם של Cassandra באמצעות גיבויים או קובץ snapshot של מכונה וירטואלית

מתחילים עם צומת אחד של Cassandra באשכול

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

מפסיקים את Cassandra בצומת:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

מסירים את תוכנת Cassandra מהצומת:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

מסירים את ספריית הנתונים מהצומת:
```
rm -rf /opt/apigee/data/apigee-cassandra
```
מורידים ומפעילים את קובץ ה-bootstrap של הגרסה הישנה של Edge for Private Cloud שאליה רוצים לחזור אחורה:

דוגמה: כדי לבצע חזרה לגרסה 4.52.01

מורידים את קובץ ה-bootstrap של גרסת 4.52.01:

curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’

מריצים את ה-bootstrap של גרסת 4.52.01:

sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

מגדירים את Cassandra בצומת:

/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile

מפסיקים את Cassandra בצומת:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

מוחקים את ספריית הנתונים בצומת:
```
rm -rf /opt/apigee/data/apigee-cassandra/data
```

שחזור הגיבוי:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file

הפעלת שירות Cassandra בצומת

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

חוזרים על השלבים בכל צומת של Cassandra בנפרד.
מריצים את הגדרת אחד מהצומתים של שרת הניהול במרכז הנתונים שבו רוצים לבצע את החזרה לאחור. מוודאים ששרת הניהול הוא מהגרסה שהוחזרה לאחור. אם לא, צריך גם לבצע חזרה לאחור של שרת הניהול.
אחרי שמסיימים את השלבים שלמעלה, מפנים את התנועה חזרה למרכז הנתונים שבו בוצעה ההחזרה לאחור.
(אופציונלי) מריצים את פקודת התיקון בכל צמתים של Cassandra בכל מרכזי הנתונים, אם יש חוסר עקביות בנתונים ביניהם.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -pr
```

החזרה לאחור של עדכון Zookeeper 3.8.3

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

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

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

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

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

ביטול העדכון של Postgres 10.17

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

אם אתם חוזרים לגרסה 4.52.01 או 4.52.00, חזרו לגרסה הקודמת של Postgres כמו שאתם חוזרים לגרסה קודמת של כל תוכנה, כפי שמתואר בקטע חזרה לגרסה ראשית או משנית קודמת שבהמשך.

חזרה לגרסה קודמת (מיור או מיינור)

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

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

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

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

/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
```
מסירים את הרכיב כדי לבצע חזרה לאחור בצומת:
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. כדי לבטל את השינויים ברכיב אחר כלשהו בצומת, צריך רק להסיר את הרכיב הזה, כפי שמתואר בדוגמה הבאה:
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  כאשר component הוא שם הרכיב.
3. כדי לבצע חזרה לאחור של Edge Router, צריך למחוק את התוכן של הקובץ /opt/nginx/conf.d בנוסף להסרת קבוצת הרכיבים edge-gateway:
```
cd /opt/nginx/conf.d
rm -rf *
```

מסירים את הגרסה 4.52.02 של apigee-setup:

/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

מתקינים את הגרסה 4.51.00 של השירות apigee-service ואת יחסי התלות שלו. בדוגמה הבאה מתבצעת התקנה של הגרסה 4.51.00 של apigee-service:
```
sudo bash /tmp/bootstrap_4.51.00.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
```
חוזרים על התהליך הזה בכל צומת שמארח את הרכיב שאתם רוצים לבצע לו חזרה לאחור.

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

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

מורידים את הגרסה הספציפית של הרכיב:
```
/opt/apigee/apigee-service/bin/apigee-service component_version install
```
כאשר component_version הוא רכיב התיקון שרוצים להתקין. לדוגמה:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui-4.51.05-0.0.3749 install
```
אם אתם משתמשים במאגר האינטרנט של Apigee, תוכלו לבדוק את הגרסאות הזמינות של הרכיבים באמצעות הפקודה הבאה:
```
yum --showduplicates list component
```
לדוגמה:
```
yum --showduplicates list edge-ui
```
משתמשים ב-apigee-setup כדי להתקין את הרכיב:
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
לדוגמה:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
```
חשוב לזכור: בזמן ההתקנה מציינים רק את שם הרכיב, ולא את הגרסה שלו.
חוזרים על התהליך הזה בכל צומת שמארח את הרכיב שאתם רוצים לבצע לו חזרה לאחור.

חזרה לגרסה הקודמת של 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