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

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

מבוא

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

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

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

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

  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

    כדי לבדוק אילו גרסאות של מסד נתונים זמינות לשדרוג במקום של גרסה ראשית, משתמשים ב-method‏ 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

    כדי לבדוק אילו גרסאות של מסד נתונים זמינות לשדרוג במקום של גרסה ראשית של מכונה, משתמשים ב-method‏ 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 מאמת את ההגדרה, המכונה לא זמינה ב-Cloud SQL.
  3. מבצע גיבוי לפני השדרוג.
  4. מבצע את השדרוג במכונה.
  5. הפעלת המכונה.
  6. מבצע גיבוי אחרי השדרוג.

המסוף

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

    כניסה לדף Cloud SQL Instances

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

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

gcloud

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

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

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

    • ‫INSTANCE_NAME: שם המכונה.
    • ‫DATABASE_VERSION: ה-enum של הגרסה הראשית של מסד הנתונים, שצריכה להיות מאוחרת יותר מהגרסה הנוכחית. מציינים גרסה של מסד נתונים לגרסה ראשית שזמינה כיעד לשדרוג של המכונה. אפשר לקבל את ה-enum הזה בשלב הראשון של התכנון לשדרוג. אם אתם צריכים רשימה מלאה של ערכי enum של גרסאות מסדי נתונים, עיינו במאמר 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 עם ה-method‏ 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 הזה בשלב הראשון של התכנון לשדרוג. לרשימה המלאה של ערכי ה-enum של גרסאות מסדי הנתונים, ראו SqlDatabaseVersion.

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

    משתמשים בבקשת GET עם ה-method‏ 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: מגדיר את אמצעי ההגנה ברמת הבסיס (root) של 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. מגדירים את פרויקט ברירת המחדל ב- Google Cloud שבו רוצים להחיל את ההגדרות של Terraform.

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

    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 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. כדי לפתוח את הדף Overview של מכונה, לוחצים על שם המכונה.

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

    הדף Logs Explorer נפתח.

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

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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