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

‫MySQL   |  PostgreSQL   |  SQL Server

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

מבוא

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

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

ב-MySQL 8.0.15 ובגרסאות קודמות, פעולת השדרוג במקום של MySQL משתמשת בכלי mysql_upgrade. ב-MySQL 8.0.16 ואילך, תהליך השדרוג במקום של MySQL מנוהל על ידי התהליך MySQL server. מידע נוסף על פעולת השדרוג במקום זמין במאמר מה משודרג בתהליך השדרוג של MySQL

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

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)

   הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

   מריצים את הפקודה הבאה:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

   ‎PowerShell (Windows)

   הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

   מריצים את הפקודה הבאה:

   $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)

   הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

   מריצים את הפקודה הבאה:

   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)

   הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

   מריצים את הפקודה הבאה:

   $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 (מידע נוסף זמין במאמר שדרוג ברירות המחדל של השרת).

   הערה: אפשר לשדרג רק מגרסה ראשית אחת לגרסה הראשית הבאה. ‫MySQL לא תומך בדילוג על גרסאות ראשיות. אי אפשר לשדרג ישירות מ-MySQL 5.6 ל-MySQL 8.0 או מ-MySQL 5.7 ל-MySQL 8.4.

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

   • אם אתם משדרגים מ-MySQL 5.7 ל-8.0, אתם צריכים לבצע בדיקה מוקדמת לשדרוגים מ-MySQL 5.7 ל-8.0. אפשר להשתמש בכלי לבדיקת שדרוג במעטפת MySQL.

   • אם אתם משדרגים מ-MySQL 8.0 ל-8.4, אתם צריכים לבצע בדיקה מוקדמת לשדרוגים מ-MySQL 8.0 ל-8.4. אפשר להשתמש בכלי לבדיקת שדרוג במעטפת MySQL.

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

     חשוב: אם אתם מריצים את כלי הבדיקה לשדרוג ל-MySQL 8.4 ממעטפת MySQL, אתם יכולים להתעלם בבטחה מהאזהרות של הבדיקה המקדימה לגבי sysvarAllowedValues ו-removedSysVars.

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
}

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

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

הערה: זה שונה מהגנה מפני מחיקה ברמת GCP (settings.deletion_protection_enabled).

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

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

• ~ עדכון במקום: הסמל הזה מציין ש-Terraform ישנה את המופע הקיים. זו התוצאה הצפויה והבטוחה לשדרוג גרסה ראשי במקום כשמשנים את database_version.
• ‫+/- יצירה מחדש (החלפה בכוח): הסמל הזה מציין ש-Terraform מתכנן להרוס את המופע הנוכחי וליצור מופע חדש.
  אזהרה: אם הסמל +/- מופיע לצד המשאב google_sql_database_instance אחרי שינוי database_version, אל תמשיכו עם terraform apply. הפעולה הזו תמחק את המופע ואת כל הנתונים שלו.
  • אם המדיניות 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.

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

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

gcloud

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

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

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

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

   gcloud sql instances patch INSTANCE_NAME \
     --database-version=DATABASE_VERSION \
     --include-replicas-for-major-version-upgrade

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

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
     "includeReplicasForMajorVersionUpgrade": true
   }

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

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

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

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

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

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

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