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

בדף הזה מוסבר איך לשדרג את הגרסה הראשית של מסד הנתונים על ידי שדרוג המכונה של Cloud SQL במקום, ולא על ידי העברת נתונים.

מבוא

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

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

תכנון שדרוג של גרסה ראשית

1. מוודאים שיש לכם את התפקיד הנדרש כדי לבצע שדרוג של גרסה ראשית: בעלים ב-Cloud SQL או אדמין ב-Cloud SQL.

2. בוחרים גרסה ראשית של היעד.

   gcloud

   במאמר התקנת ה-CLI של gcloud מוסבר איך להתקין את ה-CLI של gcloud ולהתחיל להשתמש בו. מידע על הפעלת Cloud Shell זמין במאמר בנושא שימוש ב-Cloud Shell.

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

   1. מריצים את הפקודה הבאה.

   gcloud sql instances describe INSTANCE_NAME
      

   מחליפים את INSTANCE_NAME בשם המכונה.

   2. בפלט של הפקודה, מאתרים את הקטע שמסומן בתווית upgradableDatabaseVersions.
   3. בכל קטע משנה מופיעה גרסה של מסד נתונים שזמינה לשדרוג. בכל קטע משנה, בודקים את השדות הבאים.
   • ‫majorVersion: הגרסה הראשית שאפשר לכוון אליה לשדרוג במקום.
   • ‫name: מחרוזת גרסת מסד הנתונים שכוללת את הגרסה הראשית.
   • ‫displayName: השם המוצג של גרסת מסד הנתונים.

   REST v1

   כדי לבדוק אילו גרסאות של מסד נתונים יעד זמינות לשדרוג במקום של גרסה ראשית, משתמשים בשיטה instances.get של Cloud SQL Admin API.

   לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

   • ‫INSTANCE_NAME: שם המכונה.

   ה-method של ה-HTTP וכתובת ה-URL:

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

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

   ‫Curl (Linux,‏ macOS או Cloud Shell)

   מריצים את הפקודה הבאה:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

   ‎PowerShell (Windows)

   מריצים את הפקודה הבאה:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   אתם אמורים לקבל תגובת JSON שדומה לזו:

   
   upgradableDatabaseVersions:
   
   {
     major_version: "POSTGRES_15_0"
     name: "POSTGRES_15_0"
     display_name: "PostgreSQL 15.0"
   }
   
   

   REST v1beta4

   כדי לבדוק אילו גרסאות של מסד נתונים יעד זמינות לשדרוג במקום של גרסה ראשית של מופע, משתמשים בשיטה instances.get של Cloud SQL Admin API.

   לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

   • ‫INSTANCE_NAME: שם המכונה.

   ה-method של ה-HTTP וכתובת ה-URL:

   GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

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

   ‫Curl (Linux,‏ macOS או Cloud Shell)

   מריצים את הפקודה הבאה:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

   ‎PowerShell (Windows)

   מריצים את הפקודה הבאה:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   אתם אמורים לקבל תגובת JSON שדומה לזו:

   
   upgradableDatabaseVersions:
   
   {
     major_version: "POSTGRES_15_0"
     name: "POSTGRES_15_0"
     display_name: "PostgreSQL 15.0"
   }
   
   

   רשימה מלאה של גרסאות מסד הנתונים שנתמכות ב-Cloud SQL זמינה במאמר גרסאות מסד נתונים ומדיניות גרסאות.

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

   • ‫PostgreSQL 18
   • PostgreSQL 17
   • ‫PostgreSQL 16
   • ‫PostgreSQL 15
   • ‫PostgreSQL 14
   • ‫PostgreSQL 13
   • ‫PostgreSQL 12
   • ‫PostgreSQL 11
   • ‫PostgreSQL 10

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

4. מבצעים את הבדיקה המקדימה לשדרוגים.

5. בודקים את השדרוג באמצעות הרצה יבשה.

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

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

6. מחליטים מתי לשדרג.

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

הכנה לשדרוג גרסה ראשית

לפני שמשדרגים, צריך לבצע את השלבים הבאים.

1. בודקים את הערך LC_COLLATE במסדי הנתונים template ו-postgres. קבוצת התווים של כל מסד נתונים חייבת להיות en_US.UTF8.

   אם הערך של LC_COLLATE במסדי הנתונים template ו-postgres הוא לא en_US.UTF8, השדרוג של הגרסה הראשית ייכשל. כדי לפתור את הבעיה, אם לאחד מהמסד נתונים יש ערכת תווים שונה מ-en_US.UTF8, צריך לשנות את הערך של LC_COLLATE ל-en_US.UTF8 לפני שמבצעים את השדרוג.

   כדי לשנות את הקידוד של מסד נתונים:

   1. מבצעים dump של מסד הנתונים.
   2. מחיקת מסד הנתונים.
   3. יוצרים מסד נתונים חדש עם קידוד שונה (בדוגמה הזו, en_US.UTF8).
   4. טוענים מחדש את הנתונים.

   אפשרות נוספת היא לשנות את שם מסד הנתונים:

   1. סוגרים את כל החיבורים למסד הנתונים.
   2. משנים את השם של מסד הנתונים.
   3. מעדכנים את הגדרות האפליקציה כך שישתמשו בשם החדש של מסד הנתונים.
   4. יוצרים מסד נתונים חדש וריק עם הקידוד שמוגדר כברירת מחדל.

   מומלץ לבצע את השלבים האלה במופע משוכפל לפני שמחילים אותם על מופע ייצור.

2. ניהול התוספים הנותרים ל-PostgreSQL.

   רוב התוספים פועלים בגרסה הראשית המשודרגת של מסד הנתונים. מסירים תוספים שכבר לא נתמכים בגרסת היעד. לדוגמה, צריך להסיר את התוסף chkpass אם משדרגים ל-PostgreSQL 11 או לגרסאות חדשות יותר.

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

   לפעמים, שדרוג מגרסאות 2.x של PostGIS יכול ליצור מצב שבו יש אובייקטים מיותרים במסד הנתונים שלא משויכים לתוסף PostGIS. הפעולה הזו עלולה לחסום את פעולת השדרוג. מידע על פתרון הבעיה מופיע במאמר פתרון בעיות בהתקנה של raster ב-PostGIS.

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

   מידע נוסף על שדרוג תוספי PostGIS זמין במאמר בנושא שדרוג PostGIS. לבעיות שקשורות לשדרוג PostGIS, אפשר לעיין במאמר בדיקת הגרסה של מופע PostgreSQL.
3. ניהול של דגלים מותאמים אישית במסד הנתונים. בודקים את השמות של כל הדגלים של מסד הנתונים בהתאמה אישית שהגדרתם עבור מכונת PostgreSQL. לגבי בעיות שקשורות לדגלים האלה, אפשר לעיין במאמר בדיקת הדגלים המותאמים אישית במופע PostgreSQL.
4. כשמבצעים שדרוג מגרסה ראשית אחת לגרסה ראשית אחרת, כדאי לנסות להתחבר לכל מסד נתונים כדי לבדוק אם יש בעיות תאימות. מוודאים שהמסדי נתונים יכולים להתחבר זה לזה. בודקים את השדה datallowconn בכל מסד נתונים כדי לוודא שהחיבור מותר. הערך t מציין שהחיבור מותר, והערך f מציין שאי אפשר ליצור חיבור.
5. אם אתם משתמשים בהתקנה של Datadog כדי לשדרג את מופע Cloud SQL ל-PostgreSQL 10 או לגרסאות מתקדמות יותר, אתם צריכים להסיר את הפונקציה pg_stat_activity() לפני השדרוג.

6. ניהול מקרים עם מספר גדול של אובייקטים.

   הזמן שנדרש לשדרוג גרסה מרכזית במקום תלוי במספר אובייקטי מסד הנתונים במופע. במקרים שבהם יש מספר גדול מאוד של אובייקטים, במיוחד טבלאות ואינדקסים, יכול להיות שזמני השדרוג יהיו ארוכים משמעותית. הסיכון שזמן הקצוב לתפוגה של הפעולה יחלוף גדל. ‫Cloud SQL מותאם למכונות עם עד כ-100,000 יחסים. אם המופע שלכם חורג מהמגבלה הזו, השדרוג לא ייחסם, אבל הוא ייחשב לפחות אמין ויש סיכוי גבוה יותר שהוא יימשך זמן רב או ייכשל אחרי זמן קצוב לתפוגה של 6 שעות.

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

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

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

7. ניהול מופעים באמצעות אובייקטים גדולים (LOB).

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

   כדי לבדוק את מספר האובייקטים הגדולים במסד הנתונים, מתחברים למופע של מסד הנתונים באמצעות לקוח PostgreSQL, כמו psql, ומריצים את השאילתה הבאה:

       SELECT count(*) AS total_large_objects FROM pg_largeobject_metadata;
     

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

   1. ניקוי אובייקטים גדולים יתומים: ‫PostgreSQL לא מסיר אוטומטית אובייקטים גדולים שכבר לא מפנים אליהם. כדי להסיר אובייקטים גדולים לא מאוגדים (LOB) יתומים, משתמשים בכלי השירות vacuumlo, שהוא חלק מהמודול contrib. צריך להריץ את הפקודה הזו ממכונת לקוח שיכולה להתחבר למכונה של Cloud SQL.
      • אם אין לכם vacuumlo, צריך להתקין את חבילת postgresql-contrib במכונת הלקוח.
      • מריצים את הפקודה הבאה כדי לבצע הרצה יבשה ולראות אילו קווי עסקים יימחקו:

                vacuumlo -h INSTANCE_IP -U DATABASE_USER --dry-run DATABASE_NAME
                  

        מחליפים את INSTANCE_IP, DATABASE_USER ו-DATABASE_NAME בפרטי המכונה. תוצג בקשה להזין את הסיסמה של המשתמש.
      • מריצים את הפקודה הבאה כדי להסיר את קווי המוצרים שזוהו:
        ‫

                vacuumlo -h INSTANCE_IP -U DATABASE_USER DATABASE_NAME
                  

        אחרי שמריצים את vacuumlo, בודקים שוב את מספר ה-LOB כדי לוודא שהניקוי הצליח.
   2. מחיקה ידנית של אובייקטים גדולים: בודקים את מדיניות שמירת הנתונים של האפליקציה ומסירים אובייקטים גדולים שכבר לא נחוצים.
   3. הגדלת משאבי המופע: אפשר להגדיל את הזיכרון ואת מעבדי ה-vCPU של המופע באופן זמני או קבוע. כך יש יותר משאבים לתהליך pg_upgrade.
   4. העברת הנתונים: אם אי אפשר לצמצם את מספר קווי העסקים, כדאי לשקול לשדרג את המינוי על ידי העברת הנתונים. אתם יכולים ליצור גישה מותאמת אישית באמצעות pg_dump וpg_restore במיוחד עבור יחידות עסקיות. יכול להיות ששיטות שכפול לוגיות רגילות לא יתמכו באופן מלא ב-LOB, ולכן יכול להיות שיידרשו שלבים נוספים והשבתה לצורך העברת LOB.

8. חשוב לתעד את המידע שיידרש כדי ליצור מחדש את כל משבצות השכפול הלוגיות במופע, כולל משבצות שמשמשות את pglogical, שכפול לוגי מובנה ב-PostgreSQL,‏ Datastream או כל צרכן אחר של פענוח לוגי.

מגבלות ידועות

המגבלות הבאות משפיעות על שדרוגים של גרסאות ראשיות במקום ב-Cloud SQL ל-PostgreSQL:

• אי אפשר לבצע שדרוג של גרסה ראשית במקום ברפליקה חיצונית.
• יכול להיות שייקח הרבה זמן לשדרג מופעים עם יותר מ-1,000 מסדי נתונים מגרסה אחת לגרסה אחרת, והפעולה עלולה להיכשל בגלל חריגה מזמן קצוב לתפוגה.
• משתמשים בהצהרת select * from pg_largeobject_metadata; כדי להריץ שאילתה לגבי מספר האובייקטים הגדולים בכל מסד נתונים של PostgreSQL במופע Cloud SQL. אם התוצאה מכל מסדי הנתונים שלכם היא יותר מ-10 מיליון אובייקטים גדולים, השדרוג ייכשל. מערכת Cloud SQL חוזרת לגרסה הקודמת של מסד הנתונים.
• לפני שמבצעים שדרוג במקום לגרסה ראשית של PostgreSQL 16 ואילך, צריך לשדרג את התוסף PostGIS לגרסה 3.4.0 בכל מסדי הנתונים. ב-PostgreSQL 18, צריך לשדרג ל-PostGIS גרסה 3.6.0.
• לפני שמבצעים שדרוג במקום של גרסה ראשית ל-PostgreSQL 17, צריך לשדרג את התוסף rdkit לגרסה 4.6.1 בכל מסדי הנתונים.
• לפני שמבצעים שדרוג של גרסה ראשית במקום ל-PostgreSQL 16,‏ 17 או 18, צריך לשדרג את התוסף pg_squeeze לכל מסדי הנתונים לגרסה 1.6,‏ 1.7 או 1.8 בהתאמה.
• אם אתם משתמשים ב-PostgreSQL בגרסאות 9.6,‏ 10,‏ 11 או 12, הגרסה 3.4.0 של תוסף PostGIS לא נתמכת. לכן, כדי לבצע שדרוג במקום לגרסה ראשית של PostgreSQL 16 ואילך, צריך קודם לשדרג לגרסת ביניים של PostgreSQL (גרסאות 13, 14 או 15).

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

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

הערכת מוכנות לשדרוג של המופע

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

‫Cloud SQL יכול להריץ את תהליך הבדיקה המקדימה במקביל לעומס העבודה שלכם. הפעלת בדיקה מוקדמת לפני שדרוג לגרסה הראשית יכולה לעזור למנוע כשל בשדרוג.

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

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

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

מגבלות

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

• מצב המכונה צריך להיות RUNNING.

• המכונה צריכה להיות מכונה ראשית. בדיקת ההתאמה לא תומכת במכונות משוכפלות.

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

  Operation failed because another operation was already in progress. Try
  your request after the current operation is complete.
  

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

לפני שמתחילים

• מוודאים ש-Cloud SQL Admin API מופעל במופע.
• מוודאים שיש לכם cloudsql.instances.preCheckMajorVersionUpgrade הרשאת IAM.

ביצוע בדיקה מוקדמת

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

בדיקת הממצאים של הבדיקה המקדימה

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

מוכן לשדרוג

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

לא מוכן לשדרוג

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

כל סוג בעיה כולל את השדות message ו-actions_required. כדאי לעיין בכל בעיה כדי להבין את הסוג שלה ואיך לפתור אותה. מידע נוסף על בעיות נפוצות ופתרונות זמין במאמר שגיאות נפוצות בבדיקה המקדימה לשדרוג גרסה ראשית.

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

ביצוע שדרוג של הגרסה הראשית

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

שדרוג הגרסה הראשית של מופע יחיד

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

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

resource "google_sql_database_instance" "default" {
  name             = "postgres-instance"
  region           = "us-central1"
  database_version = "POSTGRES_14"
  settings {
    tier = "db-custom-2-7680"
  }
}

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

הכללת רפליקות בשדרוג הגרסה הראשית

אם למופע הראשי יש רפליקות, אפשר לכלול את כל הרפליקות בשדרוג. ‫Cloud SQL יכול לשדרג את כל העותקים המשוכפלים של המופע הראשי, כולל עותקים משוכפלים חוצי-אזור ועקביים.

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

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

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

כדי לכלול רפליקות בשדרוג של גרסה ראשית, אי אפשר להשתמש בCloud de Confiance מסוף או ב-Terraform. אפשר להשתמש רק ב-ה-CLI של gcloud או ב-Cloud SQL Admin API.

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

כשמבצעים שדרוג של גרסה ראשית, Cloud SQL יוצר באופן אוטומטי שני גיבויים לפי דרישה, שנקראים גיבויים לשדרוג:

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

כשמציגים את רשימת הגיבויים, הגיבויים של השדרוג מופיעים עם הסוג On-demand. גיבויים לשדרוג מסומנים בתווית כדי שתוכלו לזהות אותם במהירות. לדוגמה, אם משדרגים מ-PostgreSQL 14 ל-PostgreSQL 15, הגיבוי לפני השדרוג מסומן בתווית Pre-upgrade backup, POSTGRES_14 to POSTGRES_15. והגיבוי אחרי השדרוג מסומן בתווית Post-upgrade backup, POSTGRES_14 to POSTGRES_15..

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

ביטול השדרוג של הגרסה הראשית

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

חלון הביטול

שדרוג לגרסה הראשית כולל רצף של שלבים. אפשר לבטל רק במהלך שלב השדרוג הראשי.

1. אתחול: Cloud SQL מכין את המכונה ואת המשאבים שלה. במהלך השלב הזה אי אפשר לבטל את המינוי.

2. שלב השדרוג הראשי: Cloud SQL משדרג באופן פעיל את הנתונים לגרסה הראשית החדשה. אפשר לבטל את המינוי רק בשלב הזה.

3. סיום: המופע משלים את השדרוג ומבצע אימותים סופיים.

כדי לדעת מתי המופע שלכם נכנס לשלב שבו אפשר לבטל את השדרוג, בודקים אם יש יומני שדרוג. יומני השדרוג זמינים בכתובת projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log

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

ביצוע ביטול

כדי לבטל שדרוג של גרסה ראשית במקום, צריך את מזהה הפעולה. צריך לציין את המזהה הזה בפקודה של gcloud או של API בארכיטקטורת REST, כדי שמערכת Cloud SQL תדע איזו פעולה לבטל.

אפשר להשתמש בפקודות gcloud או בפקודות של API בארכיטקטורת REST כדי לבטל פעולת שדרוג של גרסה ראשית.

POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel" | Select-Object -Expand Content

{}

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

פתרון בעיות שקשורות לביטול

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

השלמת השדרוג של הגרסה הראשית

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

1. רענון הנתונים הסטטיסטיים של מסד הנתונים.

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

2. ביצוע בדיקות קבלה.

   מריצים בדיקות כדי לוודא שהמערכת המשודרגת פועלת כמצופה.

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

פתרון בעיות בשדרוג גרסה ראשית

מערכת Cloud SQL מחזירה הודעת שגיאה אם מנסים להריץ פקודת שדרוג לא תקינה. לדוגמה, אם המכונה מכילה דגלים לא תקינים של מסד נתונים לגרסה החדשה.

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

צפייה ביומני השגיאות

אם מתרחשות בעיות בבקשת שדרוג תקינה, Cloud SQL מפרסם יומני שגיאות ב-projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log. כל רשומה ביומן מכילה תווית עם מזהה המכונה, כדי לעזור לכם לזהות את המכונה שבה אירעה שגיאת השדרוג. מחפשים שגיאות שדרוג כאלה ופותרים אותן.

כדי לראות את יומני השגיאות, משתמשים במסוף Cloud de Confiance by S3NS::

1. נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

   כניסה לדף Cloud SQL Instances

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

3. בחלונית Operations and logs בדף Overview של המופע, לוחצים על הקישור View PostgreSQL error logs.

   הדף Logs Explorer ייפתח.

4. כדי לראות את היומנים:

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

   מידע נוסף על מסנני שאילתות מופיע במאמר בנושא שאילתות מתקדמות.

   • כדי לסנן את יומני השגיאות של השדרוג עבור מופע יחיד, מזינים את השאילתה הבאה בתיבה Search all fields (חיפוש בכל השדות), אחרי שמחליפים את DATABASE_ID

   עם מזהה הפרויקט ואחריו שם המופע בפורמט הזה: project_id:instance_name.

   resource.type="cloudsql_database"
   resource.labels.database_id="DATABASE_ID"
   logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

   לדוגמה, כדי לסנן את יומני השגיאות של השדרוג לפי מופע בשם shopping-db שפועל בפרויקט buylots, משתמשים במסנן השאילתות הבא:

    resource.type="cloudsql_database"
    resource.labels.database_id="buylots:shopping-db"
    logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

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

   • מקרה חירום
   • התראה
   • קריטית
   • שגיאה

רשומות ביומן עם הקידומת pg_upgrade_dump מציינות שקרתה שגיאת שדרוג. לדוגמה:

pg_upgrade_dump: error: query failed: ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

בנוסף, רשומות ביומן שמתויגות עם שם קובץ משני .txt עשויות לכלול שגיאות אחרות שכדאי לפתור לפני שמנסים לשדרג שוב.

כל שמות הקבצים נמצאים בקובץ postgres-upgrade.log. כדי לאתר שם קובץ, צריך להסתכל בשדה labels.FILE_NAME.

שמות קבצים שעשויים להכיל שגיאות שצריך לפתור:

• tables_with_oids.txt: הקובץ הזה מכיל טבלאות שמופיעות עם מזהי אובייקטים (OID). אפשר למחוק את הטבלאות או לשנות אותן כך שלא ייעשה בהן שימוש ב-OID.
• tables_using_composite.txt: הקובץ הזה מכיל טבלאות שמופיעות באמצעות סוגים מורכבים שהוגדרו על ידי המערכת. מוחקים את הטבלאות או משנים אותן כך שלא ייעשה בהן שימוש בסוגים המורכבים האלה.
• tables_using_unknown.txt: הקובץ הזה מכיל טבלאות שמופיעות ברשימה באמצעות סוג הנתונים UNKNOWN. אפשר למחוק את הטבלאות או לשנות אותן כך שלא ישתמשו בסוג הנתונים הזה.
• tables_using_sql_identifier.txt: הקובץ הזה מכיל טבלאות שמופיעות ברשימה באמצעות סוג הנתונים SQL_IDENTIFIER. צריך למחוק את הטבלאות או לשנות אותן כך שלא ישתמשו בסוג הנתונים הזה.
• tables_using_reg.txt: הקובץ הזה מכיל טבלאות שמופיעות ברשימה באמצעות סוג הנתונים REG* (לדוגמה, REGCOLLATION או REGNAMESPACE). צריך למחוק את הטבלאות או לשנות אותן כך שלא ייעשה בהן שימוש בסוג הנתונים הזה.
• postfix_ops.txt: הקובץ הזה מכיל טבלאות שמופיעות באמצעות אופרטורים של postfix (אונריים מימין). אפשר למחוק את הטבלאות או לשנות אותן כך שלא ייעשה בהן שימוש באופרטורים האלה.

בדיקת הזיכרון

אם למופע אין מספיק זיכרון משותף, יכול להיות שתופיע הודעת השגיאה הבאה: ERROR: out of shared memory. השגיאה הזו סביר שתתרחש אם יש לכם יותר מ-10,000 טבלאות.

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

בדיקת קיבולת החיבורים

אם למופע שלכם אין מספיק קיבולת חיבור, יכול להיות שתופיע הודעת השגיאה הבאה: ERROR: Insufficient connections.

‫Cloud SQL ממליץ להגדיל את הערך של הדגל max_connections במספר מסדי הנתונים במכונה. המופע מופעל מחדש כשמשנים את הערך של הדגל הזה.

בדיקה אם יש הפניה לא ברורה לעמודה

‫Cloud SQL מבצע באופן אוטומטי בדיקה לפני השדרוג כדי לזהות תצוגות מוגדרות על ידי המשתמש שתלויות בתצוגות של קטלוג המערכת, כמו pg_stat_activity או pg_stat_replication. מבנה העמודות בתצוגות של קטלוג המערכת האלה יכול להשתנות בין גרסאות עיקריות של PostgreSQL. אם יש לכם תצוגות שselect * או מסתמכות על סדר העמודות בתצוגות המערכת האלה, יכול להיות שהן לא יהיו תואמות אחרי השדרוג, ותוצג שגיאה כמו ERROR: column reference "column_name" is ambiguous.

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

הודעת שגיאה לדוגמה

• לבעיות שקשורות ל-pg_stat_activity:

  Please remove the following usages of views that depend on functions returning
  data types of pg_stat_activity before attempting an upgrade:
  (database: my_db, schema name: public, view name: my_stat_activity_view)

• לבעיות שקשורות ל-pg_stat_replication:

  Please remove the following usages of views that depend on functions returning
  data types of pg_stat_replication before attempting an upgrade:
  (database: my_db, schema name: public, view name: my_replication_stats_view)

כדי לפתור את הבעיות האלה ולהמשיך בשדרוג: ‫1. מזהים את התצוגות שמפורטות בהודעת השגיאה של הבדיקה לפני השדרוג.

1. מחיקת התצוגות האלה באמצעות DROP VIEW view_name;.

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

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

דוגמה מפורטת יותר של הבעיה ותובנות נוספות זמינות בדיון הזה ב-Stack Overflow

בדיקה של SRF בהצהרות CASE

אם אתם משדרגים את המופע מגרסה 9.6 ומשתמשים בפונקציות להחזרת קבוצה בהצהרות CASE, יכול להיות שתופיע הודעת השגיאה ERROR: set-returning functions are not allowed in CASE. הבעיה הזו מתרחשת כי החל מגרסה 10 ואילך, אסור להשתמש בפונקציות שמחזירות קבוצה של ערכים במשפטי CASE.

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

• unnest()‎
• generate_series()
• array_agg()
• regexp_split_to_table()
• jsonb_array_elements()
• json_array_elements()
• sonb_each()
• json_each()

בדיקת תצוגות שנוצרו בשידורים בהתאמה אישית

אם יצרתם תצוגה מפורטת על סמך שידור בהתאמה אישית, תוצג הודעת שגיאה דומה לזו: ERROR: cannot cast type <type_1> to <type_2>. הבעיה הזו מתרחשת בגלל בעיות הרשאה בהפעלת Cast בהתאמה אישית.

כדי לפתור את הבעיה, צריך לעדכן את המופע לגרסה [PostgreSQL version].R20240910.01_02

מידע נוסף מופיע במאמר בנושא תחזוקה בשירות עצמי.

בדיקת הבעלות על גורם מפעיל לאירוע

ב-Cloud SQL, כל טריגרים של אירועים צריכים להיות בבעלות של משתמש עם התפקיד cloudsqlsuperuser. מערכת Cloud SQL מבצעת בדיקה לפני השדרוג כדי לאמת את הבעלות על כל טריגרי האירועים. אם טריגר של אירוע נמצא בבעלות של משתמש שאין לו תפקיד cloudsqlsuperuser, תהליך השדרוג ייעצר ותופיע הודעת שגיאה, למשל:

Please ensure that the owners of all event triggers have the cloudsqlsuperuser
role assigned to them before attempting an upgrade:
(database: your_db, triggerName your_trigger, owner: non_super_user)

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

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

SELECT
  t.evtname AS trigger_name,
  r.rolname AS current_owner
FROM pg_event_trigger t
JOIN pg_roles r ON t.evtowner = r.oid
WHERE NOT pg_has_role(r.rolname, 'cloudsqlsuperuser', 'member');

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

בדיקת עמודות שנוצרו מטבלאות שלא נרשמו

אם יש לכם טבלה שלא נרשמה ביומן ונוצרו בה עמודות, יכול להיות שתופיע הודעת השגיאה ERROR: unexpected request for new relfilenumber in binary upgrade mode. הבעיה הזו מתרחשת בגלל חוסר התאמה במאפייני ההתמדה בין טבלאות לבין הרצפים שלהן בעמודות שנוצרו.

כדי לפתור את הבעיה הזו:

1. מחיקת טבלאות שלא נרשמו ביומן: אם אפשר, מוחקים טבלאות שלא נרשמו ביומן שמקושרות לעמודות שנוצרו. לפני שממשיכים, חשוב לוודא שאפשר לצמצם את הסיכון לאובדן נתונים.
2. המרת טבלאות לטבלאות קבועות: אפשר להמיר באופן זמני טבלאות לא מתועדות לטבלאות קבועות באמצעות השלבים הבאים:
   1. המרת הטבלה לטבלה עם תיעוד ALTER TABLE SET LOGGED;
   2. ביצוע שדרוג של גרסה ראשית
   3. המרת הטבלה בחזרה לטבלה לא מתועדת ALTER TABLE SET UNLOGGED

אפשר לזהות את כל הטבלאות האלה באמצעות השאילתה הבאה :

SELECT
  relnamespace::regnamespace,
  c.relname AS table_name,
  a.attname AS column_name,
  a.attidentity AS identity_type
FROM
  pg_catalog.pg_class c
  JOIN pg_catalog.pg_attribute a ON a.attrelid = c.oid
WHERE
  a.attidentity IN ('a', 'd') AND c.relkind = 'r' AND c.relpersistence = 'u'
ORDER BY c.relname, a.attname;

בדיקת הדגלים בהתאמה אישית של מכונת PostgreSQL

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

התו הראשון של דגל מותאם אישית של מסד נתונים חייב להיות אלפביתי (A-Z או a-z). כל התווים הבאים יכולים להיות אלפאנומריים, התו המיוחד קו תחתון (_) או התו המיוחד סימן דולר ($).

הסרת תוספים

אם אתם משדרגים את המופע של Cloud SQL, יכול להיות שתופיע הודעת השגיאה הבאה: pg_restore: error: could not execute query: ERROR: role "16447" does not exist.

כדי לפתור את הבעיה, בצע את הצעדים הבאים:

1. מסירים את התוספים pg_stat_statements ו-pgstattuple.
2. מבצעים את השדרוג.
3. מתקינים מחדש את התוספים.

פעולת MVU פועלת למשך זמן ארוך יותר

יש שתי משימות בסיסיות שקשורות לשדרוג גרסה ראשית:

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

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

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

שגיאות נפוצות בבדיקה המקדימה לשדרוג גרסה ראשית

הבעיות שנמצאו על ידי בדיקת ההתאמה לפני שדרוג הגרסה הראשית מחולקות לקטגוריות הבאות:

• תוספים לא תואמים: אלה תוספים של Cloud SQL ל-PostgreSQL במופע שלא פועלים עם הגרסה הראשית החדשה.

• תלויות שלא נתמכות: אלה תלויות שלא נתמכות בגרסה הראשית החדשה או שצריך לעדכן אותן כדי שהן יפעלו איתה.

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

תוספים לא תואמים

בטבלה הבאה מפורטות שגיאות נפוצות שקשורות לתוספים לא תואמים, שסביר שיימצאו במהלך בדיקת ההתאמה לפני שדרוג הגרסה הראשית:

תלות לא נתמכת

בטבלה הבאה מפורטות שגיאות נפוצות שקשורות לתלות לא נתמכת, שסביר שהבדיקה המקדימה לשדרוג הגרסה הראשית תמצא:

חוסר תאימות של מסדי נתונים

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

שחזור המופע הראשי לגרסה הראשית הקודמת

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

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

1. מזהים את הגיבוי שלכם לפני השדרוג.

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

2. יוצרים מכונה לשחזור.

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

3. משחזרים את הגיבוי שנוצר לפני השדרוג.

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

4. מוסיפים את העותקים לקריאה.

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

5. מקשרים את האפליקציה.

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

שאלות נפוצות

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

האם המופע שלי לא זמין במהלך שדרוג?

כן. המופע לא יהיה זמין למשך תקופה מסוימת בזמן ש-Cloud SQL מבצע את השדרוג.

כמה זמן נמשך השדרוג?

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

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

האם אפשר לעקוב אחרי כל שלב בתהליך השדרוג?

ב-Cloud SQL אפשר לעקוב אחרי התקדמות פעולת השדרוג, אבל אי אפשר לעקוב אחרי השלבים הנפרדים בכל שדרוג.

האם אפשר לבטל את השדרוג אחרי שהתחלתי אותו?

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

מה קורה להגדרות שלי במהלך שדרוג?

כשמבצעים שדרוג של גרסה ראשית במקום, Cloud SQL שומר על הגדרות מסד הנתונים, כולל שם המכונה, כתובת ה-IP, ערכי הדגלים שהוגדרו במפורש ונתוני המשתמש. עם זאת, יכול להיות שערך ברירת המחדל של משתני המערכת ישתנה. לדוגמה, ערך ברירת המחדל של הדגל password_encryption ב-PostgreSQL 13 ובגרסאות קודמות הוא md5. כשמשדרגים ל-PostgreSQL 14, ערך ברירת המחדל של הדגל הזה משתנה ל-scram-sha-256.

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

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

• אפשרויות להתחברות למכונה
• איך מייבאים ומייצאים נתונים
• מידע נוסף על הגדרת דגלים של מסד נתונים