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

בדף הזה מוסבר איך לשדרג את הגרסה הראשית של מסד הנתונים על ידי שדרוג המכונה של 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_2022_STANDARD"
  name: "SQLSERVER_2022_STANDARD"
  display_name: "SQL Server 2022 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_2022_STANDARD"
  name: "SQLSERVER_2022_STANDARD"
  display_name: "SQL Server 2022 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 וההחלפה המסוכנת הזו תיחסם. כדי לאפשר את ההרס והיצירה מחדש של apply, צריך להגדיר באופן מפורש את deletion_protection = false בתצורה ולהריץ שוב את terraform 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 2017 ל-SQL Server Enterprise 2019 או ל-SQL Server Enterprise 2022, הגיבוי לפני השדרוג יסומן בתווית Pre-upgrade backup, SQLSERVER_2017_ENTERPRISE to SQLSERVER_2019_ENTERPRISE or SQLSERVER_2022_ENTERPRISE. והגיבוי אחרי השדרוג יסומן בתווית Post-upgrade backup, SQLSERVER_2019_ENTERPRISE or SQLSERVER_2022_ENTERPRISE from SQLSERVER_2017_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 2022, רמת התאימות שמוגדרת כברירת מחדל היא 160. בטבלה הזו מפורט מיפוי של גרסאות חדשות של 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. מקשרים את האפליקציה.

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

מגבלות

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

שאלות נפוצות

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

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

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

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

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

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

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

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