סקירה כללית על שדרוג גרסה משמעותי של מסד נתונים במקום

במאמר הזה מוסבר על שדרוגים של גרסאות ראשיות של מסד נתונים של AlloyDB ל-PostgreSQL במקום, שמאפשרים לשדרג מסד נתונים לגרסה חדשה יותר בלי להעביר נתונים או להחליף את המכונה הקיימת.

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

מידע נוסף זמין במאמר בנושא מדיניות לגבי גרסאות של מסדי נתונים.

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

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

הערה: כדי לאמת את תהליך השדרוג ולבדוק אם יש בעיות תאימות, מומלץ לאמת את תהליך השדרוג באשכול משוכפל לפני שמשדרגים את האשכול בפועל.

בנוסף, חברויות בתפקידים עם מעניקי הרשאות לא קיימים (חברויות יתומות) לא נשמרות. אם יש אשכול שמכיל חברויות יתומות בקטלוג pg_auth_members, החברויות האלה לתפקידים יאבדו אחרי השדרוג. מידע נוסף מופיע במאמר בנושא הכנת האשכול לשדרוג של גרסה ראשית.

תהליך עבודה לשדרוג גרסה ראשית במקום

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

1. מריץ בדיקות לפני השדרוג כדי למצוא חוסר תאימות שיכול להשפיע על השדרוג.
2. מתכונן לשדרוג הגרסה הראשית, שכולל יצירת שיבוט פנימי של האשכול.
3. הופך את המופע הראשי ללא זמין. השעות השקטות מתחילות. אפשר עדיין לקרוא דרך מאגרי קריאה.
4. מפעילה גיבוי לפני שדרוג.
5. שדרוג המופע הראשי.
6. הופך את המופעים של מאגר הקריאה ללא זמינים.
7. הופך את המופע הראשי לזמין. השעות השקטות מסתיימות.
8. מפעילה גיבוי אחרי השדרוג.
9. שדרוגים קוראים מופעים של מאגרים.

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

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

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

הערה: אפשר להמשיך להשתמש במופעים של מאגר הקריאה בזמן שמתבצע שדרוג של המופע הראשי.

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

אם שדרוג הגרסה הראשית נכשל בשלב כלשהו לפני שדרוג המופע הראשי, AlloyDB מבטל באופן אוטומטי את כל השינויים.

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

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

גודל מסד הנתונים	לפני השדרוג (ללא השבתה)	משך השתקה ראשי	קריאת נתוני זמן ההשבתה של המאגר	משך הזמן הכולל
100GB	כ-15 דקות	כ-20 דקות	כ-20 דקות	כשעה
1TB	כ-30 דקות	כ-20 דקות	כ-20 דקות	בערך שעה ו-15 דקות
4TB	כשעה	כ-20 דקות	כ-20 דקות	בערך שעה ו-45 דקות
16TB	בערך 3 שעות	כ-20 דקות	כ-20 דקות	בערך 3 שעות ו-45 דקות
‫32TB	בערך 5 שעות ו-30 דקות	כ-20 דקות	כ-20 דקות	בערך 6 שעות ו-15 דקות
‫64TB	כ-11 שעות	כ-20 דקות	כ-20 דקות	בערך 12 שעות
‫128TB	בערך 21 שעות ו-30 דקות	כ-20 דקות	כ-20 דקות	בערך 22 שעות ו-15 דקות

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

סטטוס השדרוג

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

תהליך השדרוג כולל את השלבים הבאים:

• ALLOYDB_PRECHECK
• PG_UPGRADE_CHECK
• PREPARE_FOR_UPGRADE
• PRIMARY_INSTANCE_UPGRADE
• READ_POOL_INSTANCES_UPGRADE
• ROLLBACK(רק במקרה של כשל לפני שדרוגים של מאגר הקריאה)
• CLEANUP

אלה המצבים האפשריים של השלבים האלה:

• NOT_STARTED
• IN_PROGRESS
• SUCCESS
• FAILED
• CANCEL_IN_PROGRESS
• CANCELLED

ביטולים של שדרוגים

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

ב Google Cloud מסוף, אי אפשר לבטל את הפעולה אם הלחצן ביטול השדרוג מושבת. באמצעות Google Cloud CLI או ה-API בארכיטקטורת REST, אפשר לבדוק אם אפשר לבטל את השדרוג על ידי בדיקת upgradeClusterStatus בסטטוס השדרוג:

• אם cancellable הוא true, אפשר לבטל את השדרוג.
• אם הערך של cancellable הוא false או שהוא לא מופיע בסטטוס, אי אפשר לבטל את השדרוג.

גיבויים אוטומטיים לפני השדרוג ואחריו

כשמבצעים שדרוג של גרסה ראשית, AlloyDB יוצר באופן אוטומטי את הגיבויים הרציפים הבאים, כאשר XX היא גרסת המקור הראשית ו-YY היא גרסת היעד הראשית.

• הגיבוי לפני השדרוג נוצר מיד לפני תחילת השדרוג. הגיבוי הזה נקרא בפורמט pre-upgrade-bkp-pgXX-pgYY-<uuid>. אפשר להשתמש בגיבוי הזה כדי לשחזר את המצב שלפני השדרוג. שימו לב שהשחזור לא מתבצע במקום, ושהוא יוצר אשכול חדש.
• הגיבוי אחרי השדרוג נוצר אחרי שמשדרגים את המופע הראשי. הגיבוי הזה נקרא בפורמט post-upgrade-bkp-pgXX-pgYY-<uuid>.

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

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

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

המאמרים הבאים

• שדרוג מסד נתונים בגרסה ראשית במקום.