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

בדף הזה מוסבר איך לשדרג את הגרסה הראשית של מסד הנתונים על ידי שדרוג המכונה של 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. הפעולה הזו עלולה לחסום את פעולת השדרוג. מידע על פתרון הבעיה מופיע במאמר פתרון בעיות בהתקנה של PostGIS Raster.

   לפעמים, שדרוג ל-PostGIS בגרסה 3.1.7 ומעלה לא יכול להסתיים בגלל אובייקטים שמשתמשים בפונקציות שהוצאו משימוש. הפעולה הזו עלולה לחסום את פעולת השדרוג. כדי לבדוק את סטטוס השדרוג, מריצים את הפקודה 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. הגדלת משאבי המופע: אפשר להגדיל את מספר ליבות ה-CPU הווירטואליות והזיכרון של המופע באופן זמני או קבוע. כך יש יותר משאבים לתהליך pg_upgrade.
   4. העברת הנתונים: אם אי אפשר לצמצם את מספר קווי העסקים, כדאי לשקול שדרוג על ידי העברת הנתונים. אתם יכולים ליצור גישה מותאמת אישית באמצעות pg_dump וpg_restore במיוחד עבור יחידות עסקיות. יכול להיות ששיטות שכפול לוגיות רגילות לא יתמכו באופן מלא ב-LOB, ולכן יכול להיות שיידרשו שלבים נוספים והשבתה לצורך העברת LOB.

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

ההגבלות הבאות משפיעות על שדרוגים של גרסאות ראשיות במקום ב-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 בהתאמה.
• אם אתם משתמשים בגרסאות 9.6,‏ 10,‏ 11 או 12 של PostgreSQL, גרסה 3.4.0 של תוסף PostGIS לא נתמכת. לכן, כדי לבצע שדרוג במקום של גרסה ראשית ל-PostgreSQL 16 ואילך, צריך קודם לשדרג לגרסת ביניים של PostgreSQL (גרסאות 13, 14 או 15).

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

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

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

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

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

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

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

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

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

מגבלות

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

• מצב המכונה צריך להיות 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 עם סוגי ההודעות הבאים:

אם במופע יש רק INFO או WARNING הודעות, אפשר לשדרג אותו, אבל יכול להיות שתיתקלו בבעיות אחרי השדרוג. מומלץ לבדוק את פרטי ההודעה ולפתור את הבעיה לפני השדרוג. אם במופע שלכם יש ERROR הודעות, תצטרכו לפתור את הבעיות האלה לפני השדרוג.

כל סוג בעיה כולל את השדות 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. רענון הנתונים הסטטיסטיים של מסד הנתונים.

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

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

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

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

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

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

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

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

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

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