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

בדף הזה מוסבר איך לשדרג את הגרסה הראשית של מסד הנתונים על ידי שדרוג המכונה של 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 8.4
   • ‫MySQL 8.0
   • ‫MySQL 5.7

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

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

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

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

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

6. לשדרוגים מ-MySQL 5.7 ל-MySQL 8.0, צריך לבדוק אם יש שינויים בהרשאות המשתמש ב-MySQL 8.0

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

   למידע נוסף על אופן הפעולה של הדגל הזה ב-MySQL 8.0, אפשר לעיין במאמר בנושא partial_revokes ב-MySQL 8.0.

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

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

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

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

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

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

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

1. אם אתם משדרגים מ-MySQL 8.0 ל-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 ל-8.0, ואז לשדרוג מ-MySQL 8.0 ל-8.4.

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

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

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

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

כדי לכלול רפליקות בשדרוג של גרסה ראשית, אי אפשר להשתמש בCloud de Confiance מסוף או ב-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..

בדומה לגיבויים אחרים לפי דרישה, הגיבויים של השדרוג נשמרים עד שמוחקים אותם או עד שמוחקים את המופע. אם הפעלתם 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:

   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 ל-MySQL 8.4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

• כשמשדרגים מ-MySQL 8.0 ל-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, סביר להניח שהבעיה נגרמת בגלל נתונים חדשים ולא תואמים שאולי נוספו למופע הראשי אחרי ששודרג העותק המשוכפל. במאמר הכנה לשדרוג לגרסה ראשית מוסבר איך לפתור בעיות תאימות לפני שמנסים לשדרג שוב.

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

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