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

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

מבוא

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

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

בגרסאות MySQL 8.0.15 וגרסאות קודמות, פעולת השדרוג במקום של MySQL משתמשת בכלי mysql_upgrade. בגרסאות MySQL 8.0.16 ואילך, פעולת השדרוג במקום של MySQL מטופלת על ידי התהליך MySQL server. למידע נוסף על פעולת השדרוג במקום, קראו את המאמר What the MySQL Upgrade Process Upgrades.

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

  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: מחרוזת גרסת מסד הנתונים שכוללת את הגרסה הראשית. ב-Cloud SQL ל-MySQL, השדה הזה כולל גם את הגרסה המשנית של מסד הנתונים.
      • ‫displayName: השם המוצג של גרסת מסד הנתונים.

    REST v1

    כדי לבדוק אילו גרסאות של מסד נתונים זמינות לשדרוג במקום של גרסה ראשית, משתמשים ב-method‏ instances.get של Cloud SQL Admin API.

    לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

    • ‫INSTANCE_NAME: שם המכונה.

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    REST v1beta4

    כדי לבדוק אילו גרסאות של מסד נתונים זמינות לשדרוג במקום של גרסה ראשית של מכונה, משתמשים ב-method‏ instances.get של Cloud SQL Admin API.

    לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

    • ‫INSTANCE_NAME: שם המכונה.

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

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

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

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

    אחרי שדרוג לגרסה מאוחרת יותר, יכול להיות שערך ברירת המחדל של חלק ממשתני המערכת ישתנה. לדוגמה, ערך ברירת המחדל של 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. כדי לשנות את חשבונות המשתמשים הקיימים במסד הנתונים כך שישתמשו בפלאגין האימות caching_sha2_password, משתמשים בפקודה הבאה: 
    ALTER USER 'username'@'%'
IDENTIFIED WITH caching_sha2_password BY 'user_password';
    מחליפים את username ו-user_password בערכים של חשבון המשתמש במסד הנתונים לאימות מובנה שמעדכנים.

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

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

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

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

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

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

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

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

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

מגבלות

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

  • מצב המכונה חייב להיות 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.

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

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

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

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

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

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

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

gcloud

  1. משתמשים ב- gcloud beta sql instances pre-check-major-version-upgrade כדי להריץ את הבדיקה המקדימה:

    gcloud beta sql instances pre-check-major-version-upgrade INSTANCE_NAME \
  --target-database-version=TARGET_DATABASE_VERSION \
  --project=PROJECT_ID \
  [--async]

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫INSTANCE_NAME: שם המכונה.
    • ‫TARGET_DATABASE_VERSION: הגרסה הראשית שאליה רוצים לשדרג את המכונה. כדי למצוא את גרסת מסד הנתונים, עיינו במאמר תכנון שדרוג.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

    אופציונלי: משתמשים בדגל --async כדי להריץ את הפקודה באופן אסינכרוני.

  2. אם אתם משתמשים בדגל --async כדי להריץ את הפקודה pre-check-major-version-upgrade באופן אסינכרוני, בצעו את הפעולות הבאות:

    1. מקבלים את שם הפעולה של הבדיקה המקדימה:

      משתמשים בפקודה gcloud sql operations list עם הדגל --instance:

      gcloud sql operations list --instance=INSTANCE_NAME

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫INSTANCE_NAME: שם המכונה.

    2. עוקבים אחרי הסטטוס של הבדיקה המקדימה.

      משתמשים בפקודה gcloud sql operations describe:

      gcloud sql operations describe OPERATION_NAME

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫OPERATION_NAME: שם פעולת הבדיקה המקדימה שאוחזר בשלב הקודם.
  3. אם לא מריצים את הפקודה pre-check-major-version-upgrade באופן אסינכרוני, צריך לחכות עד שהבדיקה המקדימה תסתיים כדי לראות את התוצאות.

REST v1beta4

  1. מריצים את הבדיקה המקדימה.

    לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫INSTANCE_ID: מזהה המכונה
    • ‫TARGET_DATABASE_VERSION: הגרסה הראשית שאליה רוצים לשדרג. במאמר תכנון שדרוג מפורטות הגרסאות הזמינות של מסדי הנתונים.

    ה-method של ה-HTTP וכתובת ה-URL: 

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID/preCheckMajorVersionUpgrade

    תוכן בקשת JSON: 

    {
  "preCheckMajorVersionUpgradeContext": {
    "targetDatabaseVersion": "TARGET_DATABASE_VERSION"
  }
}

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

    {
  "message": "Precheck description of finding",
  "message_type": "ERROR",
  "actions_required": [
    "Precheck action required to fix the finding"
  ]
}

  2. מקבלים את שם פעולת הבדיקה המקדימה.

    משתמשים בבקשה GET עם ה-method‏ operations.list אחרי שמחליפים את PROJECT_ID במזהה הפרויקט.

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

  3. עוקבים אחרי הסטטוס של הבדיקה המקדימה.

    משתמשים בבקשה GET עם השיטה operations.list:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operation/OPERATION_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫operation_name: שם פעולת הבדיקה המקדימה שאוחזר בשלב הקודם.

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

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

מוכן לשדרוג

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

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

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

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

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

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

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

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

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

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

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

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

ביצוע הביטול

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

gcloud

  1. מקבלים את מזהה הפעולה של הבדיקה המקדימה.

    משתמשים בפקודה gcloud sql operations list עם הדגל --instance:

    gcloud sql operations list --instance=INSTANCE_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫INSTANCE_NAME: שם המכונה.

  2. ביטול הבדיקה המקדימה.

    משתמשים בפקודה gcloud sql operations cancel:

    gcloud sql operations cancel OPERATION_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫OPERATION_ID: מזהה הפעולה שאוחזר בשלב הקודם.

REST v1beta4

  1. מקבלים את מזהה הפעולה של הבדיקה המקדימה.

    משתמשים בבקשת GET עם ה-method‏ operations.list, אחרי שמחליפים את PROJECT_ID במזהה הפרויקט.

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

  2. ביטול הבדיקה המקדימה.

    לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫OPERATION_ID: מזהה הפעולה שאוחזר בשלב הקודם.

    ה-method של ה-HTTP וכתובת ה-URL: 

    POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

    הקריאה הזו ל-API בארכיטקטורת REST לא מחזירה תשובה.

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

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

gcloud

  1. בודקים את הסטטוס "בוטל".

    משתמשים בפקודה gcloud sql operations describe:

    gcloud sql operations describe OPERATION_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫OPERATION_ID: מזהה הפעולה של הבדיקה המקדימה שבוטלה.

REST v1beta4

  1. בודקים את הסטטוס "בוטל".

    משתמשים בבקשת GET עם השיטה operations.list:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫OPERATION_ID: מזהה הפעולה של הבדיקה המקדימה שבוטלה.

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

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

הודעת שגיאה: You can't cancel operation OPERATION_ID because this operation isn't in progress.

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

הודעת שגיאה: You can't cancel operation OPERATION_ID because Cloud SQL doesn't support the cancellation of an OPERATION_TYPE operation.

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

הודעת שגיאה: The OPERATION_TYPE operation isn't cancelled. Wait and retry in a few seconds.

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

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

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

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

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

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

המסוף

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

    כניסה לדף Cloud SQL Instances

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

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

gcloud

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

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

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

    • ‫INSTANCE_NAME: שם המכונה.
    • ‫DATABASE_VERSION: ה-enum של הגרסה הראשית של מסד הנתונים, שצריכה להיות מאוחרת יותר מהגרסה הנוכחית. מציינים גרסה של מסד נתונים לגרסה ראשית שזמינה כיעד לשדרוג של המכונה. אפשר לקבל את ה-enum הזה בשלב הראשון של התכנון לשדרוג. אם אתם צריכים רשימה מלאה של ערכי enum של גרסאות מסדי נתונים, עיינו במאמר SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    שדרוגים של גרסאות ראשיות נמשכים כמה דקות. יכול להיות שתופיע הודעה שהפעולה נמשכת יותר זמן מהצפוי. אתם יכולים להתעלם מההודעה או להריץ את הפקודה gcloud sql operations wait כדי לסגור אותה.

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

    משתמשים בפקודה gcloud sql operations list עם הדגל --instance.

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

    gcloud sql operations list --instance=INSTANCE_NAME

  3. עוקבים אחרי סטטוס השדרוג.

    משתמשים בפקודה gcloud sql operations describe.

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

    gcloud sql operations describe OPERATION

REST v1

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

    משתמשים בבקשת PATCH עם ה-method‏ instances:patch.

    לפני שמשתמשים בנתוני הבקשה, צריך להחליף את המשתנים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫INSTANCE_NAME: שם המכונה.

    ה-method של ה-HTTP וכתובת ה-URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    תוכן בקשת JSON: 

    {
  "databaseVersion": DATABASE_VERSION
}

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

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

    משתמשים בבקשת GET עם ה-method‏ operations.list, אחרי שמחליפים את PROJECT_ID במזהה הפרויקט.

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. עוקבים אחרי סטטוס השדרוג.

    משתמשים בבקשת GET עם השיטה operations.get אחרי שמחליפים את המשתנים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫OPERATION_NAME: שם פעולת השדרוג שאוחזר בשלב הקודם.

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

כדי לשדרג את הגרסה הראשית של מסד הנתונים באמצעות Terraform, צריך להגדיר את הארגומנט database_version בהגדרה של המשאב google_sql_database_instance לגרסת היעד הראשית. צריך להשתמש בספק Terraform ל- Google Cloud בגרסה 4.34.0 ואילך.

הדוגמאות הבאות ממחישות הגדרה בסיסית של google_sql_database_instance. כדי לשדרג את הגרסה הראשית, מגדירים את הארגומנט database_version לגרסה הראשית הרלוונטית.

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

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

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

בדיקת התוכנית ב-Terraform

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

  • ‫~ עדכון במקום: הסמל הזה מציין ש-Terraform תשנה את המכונה הקיימת. זו התוצאה הצפויה והבטוחה של שדרוג גרסה ראשית במקום כשמשנים את database_version.
  • ‫+/- יצירה מחדש (החלפה כפויה): הסמל הזה מציין ש-Terraform מתכננת להשמיד את המכונה הנוכחית וליצור מכונה חדשה.
    • אם המדיניות deletion_protection מוגדרת לערך true, תופיע הודעת שגיאה ב-Terraform וההחלפה המסוכנת הזו תיחסם. תצטרכו להגדיר במפורש את deletion_protection = false בהגדרות ולהריץ שוב את terraform apply כדי לעדכן את המצב, לפני ש-apply הבא יאפשר את ההשמדה והיצירה מחדש.
    • אם המדיניות deletion_protection מוגדרת לערך false, המדיניות terraform apply תמשיך עם אובדן הנתונים.

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

אחרי שבודקים את הפלט של terraform plan כדי לוודא שהוא מציין רק עדכון במקום (~) לשינוי גרסת מסד הנתונים, מחילים את ההגדרות.

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

הכנת Cloud Shell

  1. מפעילים את Cloud Shell.

  2. מגדירים את פרויקט ברירת המחדל ב- Google Cloud שבו רוצים להחיל את ההגדרות של Terraform.

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

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

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

הכנת הספרייה

לכל קובץ תצורה של Terraform צריכה להיות ספרייה משלו (שנקראת גם מודול ברמה הבסיסית).

  1. יוצרים ספרייה חדשה ב-Cloud Shell ובה יוצרים קובץ חדש. שם הקובץ חייב לכלול את הסיומת .tf, למשל main.tf. במדריך הזה, הקובץ נקרא main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. אם אתם עוקבים אחרי המדריך, תוכלו להעתיק את הקוד לדוגמה בכל קטע או שלב.

    מעתיקים את הקוד לדוגמה בקובץ main.tf החדש שיצרתם.

    לחלופין, אפשר גם להעתיק את הקוד מ-GitHub. כדאי לעשות את זה כשקטע הקוד של Terraform הוא חלק מפתרון מקצה לקצה.

  3. בודקים את הפרמטרים לדוגמה ומשנים אותם בהתאם לסביבה שלכם.
  4. שומרים את השינויים.
  5. מפעילים את Terraform. צריך לעשות זאת רק פעם אחת לכל ספרייה. 
    terraform init

    אופציונלי: תוכלו לכלול את האפשרות -upgrade, כדי להשתמש בגרסה העדכנית ביותר של הספק של Google: 

    terraform init -upgrade

החלה של השינויים

  1. בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם: 
    terraform plan

    מתקנים את ההגדרות לפי הצורך.

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

    ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!‎".

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

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

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

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

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

    לפני שמשתמשים בנתוני הבקשה, צריך להחליף את המשתנים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫INSTANCE_NAME: שם המכונה.

    ה-method של ה-HTTP וכתובת ה-URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    תוכן בקשת JSON: 

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

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

    משתמשים בבקשת GET עם ה-method‏ operations.list, אחרי שמחליפים את PROJECT_ID במזהה הפרויקט.

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. עוקבים אחרי סטטוס השדרוג.

    משתמשים בבקשת GET עם השיטה operations.get אחרי שמחליפים את המשתנים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫OPERATION_NAME: שם פעולת השדרוג שאוחזר בשלב הקודם.

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

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

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

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

    הדף Logs Explorer נפתח.

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

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

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

    • כדי לסנן את יומני השגיאות של השדרוג למכונה אחת, מזינים את השאילתה הבאה בתיבה Search all fields, אחרי שמחליפים את DATABASE_ID

    עם מזהה הפרויקט ואחריו שם המכונה בפורמט הזה: project_id:instance_name.

    resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%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"

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

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

    יכול להיות שתיתקלו בבעיות מוכרות במהלך הבדיקה המקדימה והשדרוג מגרסה 5.7 של MySQL לגרסה 8.0 של MySQL. כדי לקבל עזרה בפתרון הבעיות האלה, קראו את המאמר פתרון בעיות בשדרוג גרסה ראשית במקום ל-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 זמין במאמרים Preparing your installation for upgrade ו-Upgrading to MySQL 8.0?.

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

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

    אם אתם עדיין משתמשים בפקודות או בהגדרות עם המונחים האלה, אתם צריכים להחליף או להסיר אותם. למידע נוסף על ההסרה וההחלפה של המונחים האלה, קראו את המאמר What Is New in MySQL 8.4 since 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, החשבונות האלה לא יכולים להתחבר למסד הנתונים. לפני שמשדרגים ל-Cloud SQL ל-MySQL 9.7, צריך לשנות את כל החשבונות שנותרו כך שישתמשו בפלאגין caching_sha2_password.

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

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

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

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

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