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

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

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

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

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

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

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

כשמתחילים שדרוג באשכול, 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), צריך שיהיה גיבוי של גרסה. השחזור לא זמין באשכול המשודרג עד שהגיבוי שאחרי השדרוג, או גיבוי אחר שמופעל אחרי שדרוג המופע הראשי, מסתיים.

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