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

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

מבוא

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

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

פעולת השדרוג במקום של Cloud SQL ל-SQL Server משתמשת בכלי SQL Server upgrade in-place.

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

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

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

    gcloud

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

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

    1. מריצים את הפקודה הבאה.
      2. 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

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

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

    
upgradableDatabaseVersions:

{
  major_version: "SQLSERVER_2025_STANDARD"
  name: "SQLSERVER_2025_STANDARD"
  display_name: "SQL Server 2025 Standard"
}

    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

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

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

    
upgradableDatabaseVersions:

{
  major_version: "SQLSERVER_2025_STANDARD"
  name: "SQLSERVER_2025_STANDARD"
  display_name: "SQL Server 2025 Standard"
}

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

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

    אפשר לעיין בתכונות שהוצאו משימוש ובשינויים שעלולים לשבור את התאימות ב-SQL Server.

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף סקירה כללית של מכונה, לוחצים על שם המכונה.
  3. לוחצים על Edit.
  4. בקטע פרטי המופע, לוחצים על הלחצן שדרוג ומאשרים שרוצים לעבור לדף השדרוג.
  5. בדף Choose a database version (בחירת גרסת מסד נתונים), לוחצים על הרשימה Database version for upgrade (גרסת מסד הנתונים לשדרוג) ובוחרים אחת מגרסאות מסד הנתונים העיקריות שזמינות.
  6. לוחצים על Continue.
  7. בתיבה Instance ID (מזהה מופע), מזינים את שם המופע ולוחצים על הלחצן Start upgrade (התחלת השדרוג).
הפעולה תימשך כמה דקות.

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

gcloud

  1. מתחילים את השדרוג.

    משתמשים בפקודה gcloud sql instances patch עם הדגל --database-version.

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

    • ‫INSTANCE_NAME: השם של המכונה.
    • ‫DATABASE_VERSION: ערך ה-enum של הגרסה הראשית של מסד הנתונים, שצריך להיות מאוחר יותר מהגרסה הנוכחית. מציינים גרסת מסד נתונים עבור גרסה ראשית שזמינה כיעד שדרוג למופע. אפשר לקבל את ה-enum הזה כשלב הראשון של Plan for upgrade. אם אתם צריכים רשימה מלאה של סוגי הנתונים של גרסאות מסד הנתונים, תוכלו לעיין בSqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    שדרוגים של גרסאות ראשיות נמשכים כמה דקות. יכול להיות שתופיע הודעה שמציינת שהפעולה נמשכת יותר זמן מהצפוי. אתם יכולים להתעלם מההודעה הזו או להריץ את הפקודה gcloud sql operations wait כדי לסגור אותה.

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

    משתמשים בפקודה gcloud sql operations list עם הדגל --instance.

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

    gcloud sql operations list --instance=INSTANCE_NAME

  3. בודקים את סטטוס השדרוג.

    משתמשים בפקודה gcloud sql operations describe.

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

    gcloud sql operations describe OPERATION

REST v1

  1. מתחילים את השדרוג במקום.

    משתמשים בבקשת PATCH עם השיטה instances:patch.

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

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫INSTANCE_NAME: השם של המכונה.

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

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

    תוכן בקשת JSON: 

    {
  "databaseVersion": DATABASE_VERSION
}

    מחליפים את DATABASE_VERSION בערך enum של הגרסה הראשית של מסד הנתונים, שחייבת להיות מאוחרת מהגרסה הנוכחית. מציינים גרסת מסד נתונים עבור גרסה ראשית שזמינה כיעד שדרוג למופע. אפשר לקבל את ה-enum הזה כשלב הראשון של Plan for upgrade. אם אתם צריכים רשימה מלאה של סוגי גרסאות מסד נתונים, תוכלו לעיין ב-SqlDatabaseVersion.

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

    משתמשים בבקשת GET עם השיטה operations.list אחרי שמחליפים את PROJECT_ID במזהה הפרויקט.

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

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. בודקים את סטטוס השדרוג.

    משתמשים בבקשת GET עם השיטה operations.get אחרי שמחליפים את המשתנים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫OPERATION_NAME: שם פעולת השדרוג שאוחזר בשלב הקודם.

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

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

כדי לשדרג את הגרסה הראשית של מסד הנתונים באמצעות Terraform, צריך להגדיר את הארגומנט database_version בהגדרת המשאב google_sql_database_instance לגרסה הראשית של היעד. חובה להשתמש בספק Terraform ל Google Cloud גרסה 4.34.0 ואילך.

בדוגמאות הבאות מוסבר איך להגדיר google_sql_database_instance בסיסי. כדי לשדרג את הגרסה הראשית, מגדירים את הארגומנט database_version לגרסה הראשית הרלוונטית.

resource "google_sql_database_instance" "default" {
  name             = "sqlserver-instance"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"
  settings {
    tier = "db-custom-2-7680"
  }
}

מבצעים את השינויים הבאים בארגומנטים של Terraform:

  • database_version: מגדירים את הגרסה הראשית של היעד לשדרוג.
  • ‫deletion_protection: מגדיר את אמצעי ההגנה של Terraform ברמת הבסיס מפני מחיקת מופעים.
    • ‫true: מונע מ-Terraform להרוס את המופע. כל פעולת Terraform שמתוכננת למחוק את המשאב הזה נחסמת.
    • ‫false: מאפשר ל-Terraform למחוק את המופע.

בדיקת התוכנית של Terraform

לפני שמיישמים שינויים, תמיד מריצים את הפקודה terraform plan ובודקים בקפידה את הפלט. הסמלים שמופיעים לצד שם המשאב מציינים איך Terraform יחיל את השינויים:

  • ~ עדכון במקום: הסמל הזה מציין ש-Terraform ישנה את המופע הקיים. זהו התוצאה הצפויה והבטוחה לשדרוג גרסה ראשי במקום, כשמשנים את database_version.
  • ‫+/- יצירה מחדש (החלפה בכוח): הסמל הזה מציין ש-Terraform מתכננת להרוס את המופע הנוכחי וליצור מופע חדש.
    • אם deletion_protection מוגדר ל-true, תופיע שגיאה ב-Terraform וההחלפה המסוכנת הזו תיחסם. כדי לעדכן את הסטטוס, צריך להגדיר באופן מפורש את deletion_protection = false בהגדרה ולהריץ שוב את terraform apply. רק אחרי זה אפשר יהיה להפעיל את הפקודה apply כדי להרוס וליצור מחדש.
    • אם הערך של deletion_protection מוגדר כ-false, המערכת של terraform apply תמשיך במחיקת הנתונים.

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

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

כדי להחיל את הגדרות Terraform בפרויקט ב- Google Cloud , מבצעים את השלבים בקטעים הבאים.

הכנת Cloud Shell

  1. מפעילים את Cloud Shell.

  2. מגדירים את פרויקט ברירת המחדל שבו רוצים להחיל את ההגדרות של Terraform. Google Cloud

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

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

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

הכנת הספרייה

לכל קובץ תצורה של Terraform צריכה להיות ספרייה משלו (שנקראת גם מודול ברמה הבסיסית).

  1. יוצרים ספרייה חדשה ב-Cloud Shell ובה יוצרים קובץ חדש. שם הקובץ חייב לכלול את הסיומת .tf, למשל main.tf. במדריך הזה, הקובץ נקרא main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

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

    מעתיקים את הקוד לדוגמה בקובץ main.tf החדש שיצרתם.

    לחלופין, אפשר גם להעתיק את הקוד מ-GitHub. כדאי לעשות את זה כשקטע הקוד של Terraform הוא חלק מפתרון מקצה לקצה.

  3. בודקים את הפרמטרים לדוגמה ומשנים אותם בהתאם לסביבה שלכם.
  4. שומרים את השינויים.
  5. מפעילים את Terraform. צריך לעשות זאת רק פעם אחת לכל ספרייה. 
    terraform init

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

    terraform init -upgrade

החלה של השינויים

  1. בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם: 
    terraform plan

    מתקנים את ההגדרות לפי הצורך.

  2. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform: 
    terraform apply

    ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!‎".

  3. פותחים את Google Cloud הפרויקט כדי לראות את התוצאות. במסוף Google Cloud , נכנסים למשאבים בממשק המשתמש כדי לוודא שהם נוצרו או עודכנו ב-Terraform.

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

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

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

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

כשמציגים את רשימת הגיבויים, הגיבויים של השדרוג מופיעים עם הסוג On-demand. גיבויים לשדרוג מסומנים בתווית כדי שתוכלו לזהות אותם במהירות. לדוגמה, אם משדרגים מ-SQL Server Enterprise 2019 ל-SQL Server Enterprise 2022 או ל-SQL Server Enterprise 2025, הגיבוי לפני השדרוג יסומן בתווית Pre-upgrade backup, SQLSERVER_2019_ENTERPRISE to SQLSERVER_2022_ENTERPRISE or SQLSERVER_2025_ENTERPRISE. והגיבוי אחרי השדרוג יסומן בתווית Post-upgrade backup, SQLSERVER_2022_ENTERPRISE or SQLSERVER_2025_ENTERPRISE from SQLSERVER_2019_ENTERPRISE..

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

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

רמת התאימות של מסד הנתונים קובעת את אופן הפעולה של מסד הנתונים ביחס לאפליקציה שהוא משרת. ההגדרה של רמת התאימות של מסד הנתונים מבטיחה תאימות לדור קודם עם גרסאות קודמות של SQL Server, וקשורה לשינויים ב-Transact-SQL וב-Query Optimizer. כשמשדרגים גרסה של מסד נתונים של מופע SQL Server, רמות התאימות של מסדי נתונים קיימים נשמרות, כך שהאפליקציה יכולה להמשיך לפעול בגרסה העדכנית יותר של SQL Server. שדרוג רמת התאימות מאפשר לכם ליהנות מתכונות חדשות, משיפורים בעיבוד שאילתות ומשינויים אחרים.

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

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

  1. מזהים את רמת התאימות הנוכחית של מסד הנתונים.

    לדוגמה, ב-SQL Server 2017, רמת התאימות שמוגדרת כברירת מחדל היא 140. כדי לבדוק את רמת התאימות הנוכחית של מסד הנתונים, מריצים את הפקודה הבאה ב-Transact-SQL, אחרי שמחליפים את DATABASE_NAME

    עם השם של מסד הנתונים במופע של SQL Server.

    USE DATABASE_NAME
GO
SELECT compatibility_level
FROM sys.databases WHERE name = 'DATABASE_NAME'

  2. קובעים את רמת התאימות לטירגוט.

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

  3. בודקים את ההבדלים בין רמות התאימות הנוכחיות לרמות התאימות הרצויות.

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

  4. איסוף נתונים בסיסיים של עומס העבודה.

    לפני שמשדרגים את רמת התאימות, כדאי לאסוף נתוני בסיס של עומס העבודה באמצעות SQL Server Query Store, כדי שתוכלו לזהות ולטפל בשאילתות שהביצועים שלהן ירדו. אתם משתמשים במאגר השאילתות כדי לתעד שאילתות ותוכניות עבור מחזור עסקי טיפוסי כדי ליצור בסיס להשוואה של הביצועים. כדי לקבל תהליך עבודה מודרך, משתמשים בתכונה Query Tuning Assistant ב-SQL Server Management Studio.

  5. משדרגים את רמת התאימות.

    כדי לשנות את רמת התאימות של מסד הנתונים, מריצים את הפקודה הבאה ב-Transact-SQL, אחרי שמחליפים את DATABASE_NAME

    עם שם מסד הנתונים במופע של SQL Server ועם TARGET_COMPATIBILITY_LEVEL רמת התאימות לטירגוט.

    ALTER DATABASE DATABASE_NAME
SET COMPATIBILITY_LEVEL = TARGET_COMPATIBILITY_LEVEL;
GO

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

    אוספים נתונים משודרגים של עומסי עבודה באמצעות Query Store לצורך השוואה וזיהוי רגרסיה.

  7. טיפול בשאילתות שחלה בהן נסיגה.

    ברוב המקרים, שינויים ב-Query Optimizer ברמות תאימות משודרגות משפרים את הביצועים. עם זאת, מעת לעת, הביצועים של שאילתות מסוימות עשויים להידרדר. התכונה Regressed Queries ב-Query Store עוזרת לכם לזהות את השאילתות שחלה בהן רגרסיה, ומאפשרת לכם לכפות את תוכנית השאילתה האחרונה שהייתה תקינה. ב-SQL Server יש גם תיקון אוטומטי של תוכנית, שיכול לעבור אוטומטית לתוכנית האחרונה שהייתה תקינה במקרה של רגרסיה בשאילתה.

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

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

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

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

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

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

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

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

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

    כניסה לדף Cloud SQL Instances

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

  3. בחלונית Operations and logs בדף Overview של המופע, לוחצים על הקישור View SQL Server 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%2Fsqlserver.err"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

  • אי אפשר לבצע שדרוג של גרסה ראשית במקום ברפליקה חיצונית.
  • במהלך השדרוג ל-SQL Server 2025, יכול להיות שמופעים עם זיכרון RAM בנפח של 4GB או פחות יהפכו לאיטיים או לא יגיבו, מה שיגרום לכך שהפעולה תיכשל. כדי למנוע את הבעיה הזו, חשוב לוודא שלמופע יש זיכרון RAM בנפח של 8GB לפחות לפני שמשדרגים. אחרי שהשדרוג יסתיים, תוכלו להקטין את גודל המכונה.

שאלות נפוצות

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

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

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

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

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

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

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

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