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

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

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

גודל מסד הנתונים	שדרוג מוקדם (ללא זמן השבתה)	זמן השבתה ראשי	קריאה של נתוני זמן ההשבתה של המאגר	משך כולל
100GB	כ-15 דקות	כ-20 דקות	כ-20 דקות	כשעה
1TB	כ-30 דקות	כ-20 דקות	כ-20 דקות	כשעה ורבע
4TB	כשעה	כ-20 דקות	כ-20 דקות	בערך שעה ו-45 דקות
16TB	בערך 3 שעות	כ-20 דקות	כ-20 דקות	כ-3 שעות ו-45 דקות
32 TB	כ-5 שעות ו-30 דקות	כ-20 דקות	כ-20 דקות	בערך 6 שעות ו-15 דקות
64 TB	בערך 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 , אם הלחצן Cancel upgrade מופיע באפור, אי אפשר לבטל את הפעולה. כדי לבדוק אם אפשר לבטל את השדרוג, אתם יכולים להשתמש ב-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), צריך שיהיה גיבוי של גרסה. השחזור לא זמין באשכול המשודרג עד לסיום הגיבוי שלאחר השדרוג, או עד לסיום גיבוי אחר שמתחיל אחרי שדרוג המכונה הראשית.

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

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