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

בדף הזה מוסבר איך לשדרג את הגרסה הראשית של מסד הנתונים על ידי שדרוג המכונה של 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: מחרוזת גרסת מסד הנתונים שכוללת את הגרסה הראשית. ב-Cloud SQL ל-MySQL, השדה הזה כולל גם את הגרסה המשנית של מסד הנתונים.
   • ‫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: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   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: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

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

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

   • ‫MySQL 9.7
   • ‫MySQL 8.4
   • ‫MySQL 8.0
   • ‫MySQL 5.7

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

   אחרי שדרוג לגרסה מאוחרת יותר, ערך ברירת המחדל של חלק ממשתני המערכת עשוי להשתנות. לדוגמה, ערך ברירת המחדל של character_set_server ב-MySQL 5.6 וב-MySQL 5.7 הוא utf8. כשמשדרגים ל-MySQL 8.0, ערך ברירת המחדל של character_set_server משתנה ל-utf8mb4. כדי לחזור לגרסה utf8, צריך לשנות באופן ידני את ערך הדגל של מסד הנתונים לערך הקודם שלו. מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים. רוב השינויים בערכי ברירת המחדל מתבצעים על ידי קהילת MySQL (מידע נוסף זמין במאמר שדרוג ברירות המחדל של השרת).

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

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

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

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

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

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

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

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

1. אם אתם משדרגים מ-MySQL 8.0 ל-MySQL 8.4, אתם צריכים לעדכן את תוסף האימות של חשבונות המשתמשים הקיימים שלכם כדי להשתמש בתוסף האימות caching_sha2_password במקום בתוסף mysql_native_password שהוצא משימוש. כדי לשנות את חשבונות המשתמשים הקיימים במסד הנתונים כך שישתמשו בתוסף האימות caching_sha2_password, מריצים את הפקודה הבאה:

   ALTER USER 'username'@'%'
   IDENTIFIED WITH caching_sha2_password BY 'user_password';
        

   מחליפים את username ואת user_password בערכים של חשבון המשתמש במסד הנתונים של אימות מובנה שאתם מעדכנים.

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

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

הגדרות שנדרשות לשימוש ב-MySQL 8.4 ואילך עם שרת ה-proxy ל-Cloud SQL Auth

כשמשתמשים ב-MySQL מגרסה 8.4 ואילך עם Cloud SQL Auth Proxy, צריך להגדיר את הגדרות מסד הנתונים של האפליקציה עם הגדרת MySQL‏ allowPublicKeyRetrieval=true. לפני שמשדרגים את גרסת מסד הנתונים, צריך לשדרג את אפליקציות הלקוח עם ההגדרה הזו.

לדוגמה, אם משתמשים בלקוח mysql, צריך להשתמש בדגל --get-server-public-key:

mysql -u username -p --get-server-public-key

אם אתם משתמשים בשפת התכנות Java, אתם יכולים להשתמש בפקודה הבאה:

config.setJdbcUrl("jdbc:mysql://" + dbHost + ":" + dbPort + "/" + dbName);
config.addDataSourceProperty("allowPublicKeyRetrieval", "true");

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

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

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

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

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

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

מגבלות

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

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

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

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

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

• בדיקת התאימות בודקת את התאימות של השדרוג בין גרסאות ראשיות עוקבות של Cloud SQL ל-MySQL. לדוגמה, אפשר להריץ בדיקה מוקדמת לשדרוג בין MySQL 5.7 ל-MySQL 8.0, לשדרוג בין MySQL 8.0 ל-MySQL 8.4, ואז לשדרוג בין MySQL 8.4 ל-MySQL 9.7.

  הכלי לבדיקה מוקדמת לא תומך בבדיקה של שדרוג לגרסה משנית בתוך אותה גרסה ראשית. לדוגמה, אי אפשר לבצע בדיקה מוקדמת לשדרוג מ-MySQL 8.0.31 ל-8.0.45.

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

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

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

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

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

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

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

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

מוכן לשדרוג

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

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

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

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

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

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

אפשר לבטל פעולת בדיקה מראש של שדרוג גרסה ראשית ב-Cloud SQL ל-MySQL.

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

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

מזהה הפעולה מוחזר בשדה name של התגובה.

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

ביצוע ביטול

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

בדיקת סטטוס הביטול

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

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

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

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

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

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

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

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
}

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

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

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

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

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

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

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

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

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

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

כשמציגים את רשימת הגיבויים, הגיבויים של השדרוג מופיעים עם הסוג On-demand. גיבויים שנוצרו במהלך שדרוג מסומנים כדי שתוכלו לזהות אותם במהירות. לדוגמה, אם משדרגים מ-MySQL 5.7 ל-MySQL 8.0, הגיבוי לפני השדרוג יסומן בתווית Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. והגיבוי אחרי השדרוג יסומן בתווית Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.. אם משדרגים מ-MySQL 8.0 ל-MySQL 8.4, הגיבוי לפני השדרוג יסומן בתווית Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. והגיבוי אחרי השדרוג יסומן בתווית Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0.. אם משדרגים מ-MySQL 8.4 ל-MySQL 9.7, הגיבוי לפני השדרוג יסומן בתווית Pre-upgrade backup, MYSQL_8_4 to MYSQL_9_7. והגיבוי אחרי השדרוג יסומן בתווית Post-upgrade backup, MYSQL_9_7 from MYSQL_8_4..

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

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

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

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

2. אופציונלי: עדכון הרשאות המשתמש.

   ב-MySQL 8.0 יש שינויים חדשים במערכות האבטחה ובניהול החשבונות. מידע נוסף זמין במאמר What is New in MySQL 8.0.

   ב-Cloud SQL ל-MySQL, השינויים האלה אומצו וההרשאות של המשתמשים שמשויכות לתפקיד cloudsqlsuperuser שופרו. יכול להיות שלמשתמשים שנוצרו בגרסה MySQL 5.7 של המופע לא יהיו אותן הרשאות כמו למשתמשים שנוצרו ישירות ב-MySQL 8.0. לדוגמה, למשתמשים שמשדרגים מ-MySQL 5.7 ל-MySQL 8.0 אין את ההרשאה CONNECTION_ADMIN. כתוצאה מכך, הם לא יכולים להריץ את הפקודה KILL בסשנים של משתמשים אחרים. כדי ללמוד איך לעדכן את הרשאות המשתמש, אפשר לעיין בהליך שמופיע בקטע הזה.

   אם משדרגים מ-MySQL 8.0 ל-MySQL 8.4, יש שינויים נוספים בהרשאות המשתמש, כולל הוספה של הרשאות שהוצגו ב-MySQL 8.4 והסרה של הרשאות שהיו קיימות ב-MySQL 8.0. למידע נוסף, ראו הרשאות משתמש ב-MySQL 8.4 (cloudsqlsuperuser).

   כדי לעדכן את הרשאות המשתמש ב-MySQL 8.0, ב-MySQL 8.4 או ב-MySQL 9.7:

   1. יצירת משתמש עם התפקיד cloudsqlsuperuser שהוקצה לו כברירת מחדל.

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

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

      SHOW GRANTS for 'admin'@'%',

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

      GRANT CONNECTION_ADMIN ON *.* to 'admin'@'%';

      כדי להקצות את התפקיד cloudsqlsuperuser למשתמש admin'@'%, מריצים את הפקודה הבאה:

      GRANT 'cloudsqlsuperuser' to 'admin'@'%';

3. אופציונלי: יוצרים גיבוי.

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

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

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

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

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

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

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

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

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

   כניסה לדף Cloud SQL Instances

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

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

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

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

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

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

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

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

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

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

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

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

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

בעיות נפוצות שמתגלות בשדרוגים מ-MySQL 5.7 ל-MySQL 8.0 יכולות לכלול:

• הוספה של מילות מפתח חדשות שמורות, כמו RANKS,‏ GROUPS,‏ FUNCTION, בפרוצדורות מאוחסנות, בטריגרים ובאובייקטים אחרים במסד הנתונים. מידע נוסף זמין במאמר בנושא מילות מפתח ומילים שמורות.
• תווי UTF לא תקינים בהגדרות הטבלה.
• מעברי XA שלא בוצעו וצריך לבצע אותם (באמצעות ההצהרה XA COMMIT) או לבטל אותם (באמצעות ההצהרה XA ROLLBACK).
• הגבלת מפתח זר בשמות ארוכים מ-64 תווים.
• סוג נתונים מרחביים באינדקס מעורב של עמודות. מידע נוסף זמין במאמר סוג נתונים מרחביים.

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

בעיות נפוצות שמתגלות בשדרוגים מ-MySQL 8.0 ל-MySQL 8.4 יכולות לכלול:

• טרמינולוגיה מיושנת של שכפול. המונחים MASTER ו-SLAVE הוסרו לחלוטין מ-MySQL 8.4.

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

בעיות נפוצות שמתגלות בשדרוגים מ-MySQL 8.4 ל-MySQL 9.7 יכולות לכלול:

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

  Non-vector secondary indexes are disallowed on vector columns when cloudsql_vector is enabled.

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

• יש לכם הטמעות וקטורים קיימות במסד הנתונים של Cloud SQL 8.4, אבל העברתם את cloudsql_vector ל-off. במסגרת השדרוג ל-MySQL 9.7, כל נתוני הווקטורים מועברים לפורמט הקהילתי של MySQL במקום לפורמט VARBINARY שבו נעשה שימוש במסדי נתונים של Cloud SQL ל-MySQL 8.4 וגרסאות קודמות. כדי לוודא שנתוני הווקטור מועברים בצורה נכונה, אפשר לעדכן את הדגל cloudsql_vector ל-on ולהמשיך בשדרוג ל-MySQL 9.7. במהלך השדרוג, נתוני הווקטור מועברים לפורמט מבוסס-קהילה. לחלופין, אפשר להשאיר את הדגל cloudsql_vector מוגדר לערך off ולמחוק את נתוני הווקטור באופן ידני במסד הנתונים של MySQL 8.4 לפני השדרוג.
• נותרו לכם חשבונות משתמשים מובנים במסד הנתונים שמשתמשים בתוסף mysql_native_password. הפלאגין מוסר לחלוטין מ-Cloud SQL ל-MySQL 9.7. אם יש חשבונות משתמשים שמשתמשים בתוסף mysql_native_password, הם לא יוכלו להתחבר למסד הנתונים שלכם. צריך לשנות את כל החשבונות שנותרו כך שישתמשו בתוסף caching_sha2_password לפני השדרוג ל-Cloud SQL ל-MySQL 9.7.

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

• אי אפשר לבצע שדרוג של גרסה ראשית במקום ברפליקה חיצונית.
• שדרוג מכונות מ-MySQL 5.7 ל-MySQL 8.0 עם יותר מ-512,000 טבלאות עשוי להימשך זמן רב ולהסתיים בפסק זמן.
• שדרוג מכונות מ-MySQL 8.0 ל-MySQL 8.4 עם יותר מ-512,000 טבלאות עלול להימשך זמן רב ולהסתיים בפסק זמן.

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

  CREATE USER 'USERNAME'@'%' IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

  מחליפים את USERNAME ו-PASSWORD בערכים המתאימים.

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. שדרוג המכונה הראשית

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

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

אם השדרוג לא מצליח, העותק חוזר לגרסה של המופע הראשי. אפשר לשדרג שוב את העותק המשוכפל, אבל אם הבעיה נמשכת, אפשר לבדוק את היומן mysql.err בעותק המשוכפל כדי למצוא את המקור. מחפשים מילות מפתח כמו [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

אם הודעת השגיאה מכילה את Access denied for AuthId.... עם שינויים בהרשאות המשתמש, סביר להניח שמתבצעת שאילתה באמצעות הרשאות משתמש של MySQL 5.7 בסכימות mysql ו-sys, והיא עלולה להיכשל בגלל השינויים במערכות האבטחה וניהול החשבונות ב-MySQL 8.0. כדי לפתור את הבעיה, צריך להפסיק את השאילתות במופע הראשי לפני שמשדרגים את המופע הראשי לגרסה החדשה, ואז לנסות שוב לשדרג את העותק. ‫Cloud SQL ממליץ להפסיק באופן זמני את כל השאילתות האלה גם במכונה הראשית לפני השדרוג לגרסה החדשה, כי הן עלולות לגרום לבעיה דומה.

אם לא מופיעה הסיבה לכשל, כמו Access denied for AuthID.... ביומני MySQL, סביר להניח שהבעיה נגרמת מנתונים חדשים ולא תואמים שאולי נוספו למופע הראשי אחרי ששודרג העותק המשוכפל. במאמר הכנה לשדרוג לגרסה ראשית מוסבר איך לפתור בעיות תאימות לפני שמנסים לשדרג שוב.

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

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