שדרוג במקום

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

ביצוע שינויים במקום במכונה של Cloud SQL

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

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

מוודאים שהמופע פועל ב-MySQL בגרסה 8.0.31 ואילך.

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

שימו לב לשינויים פוטנציאליים באחסון שקשורים לסוג המכונה

מהדורות שונות תומכות בסוגים שונים של מכונות שמשתמשות באפשרויות אחסון שונות. סוגי המכונות C4 ו-C4A עם הביצועים הגבוהים משתמשים באחסון Hyperdisk Balanced ולא באחת מהאפשרויות של דיסק מתמשך שבהן נעשה שימוש בסוגי מכונות ישנים יותר.

כשמשנים את המהדורה או את סוג המכונה שבהם משתמשים, יכול להיות שגם סוג האחסון ישתנה. שינוי כזה עלול לגרום להשבתה זמנית ולשינוי בעלויות האחסון. כשעוברים ל-Google Cloud Hyperdisk Balanced, יש אפשרויות הגדרה נוספות שאפשר לציין. מידע נוסף זמין במאמר בנושא שינויים בנפח האחסון.

שימו לב לשינויים באחסון של יומן העסקאות של PITR

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

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

שינוי המהדורה של מופע במקום

בקטע הזה נסביר איך לשנות את המהדורה של מופע Cloud SQL במקום למהדורת Cloud SQL Enterprise Plus או ממהדורת Cloud SQL Enterprise Plus. מהדורת Cloud SQL Enterprise Plus מציעה כמה יתרונות ושיפורים בביצועים שלא קיימים במהדורת Cloud SQL Enterprise. מידע נוסף על מהדורות Cloud SQL זמין במאמר סקירה כללית על מהדורות Cloud SQL.

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

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

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

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

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

אפשרויות לשינויים במקום

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

שינויים במכונה

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

כשמשדרגים ממהדורת Cloud SQL Enterprise למהדורת Cloud SQL Enterprise Plus, אפשר לבחור בין סדרות המכונות N2,‏ C4A ו-C4.

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

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

מידע כללי נוסף זמין גם במאמרי העזרה של Compute Engine בנושא סדרות המכונות N2,‏ C4A,‏ C4 ו-N4.

שינויים באחסון

אם אתם עוברים מסדרת מכונות למטרות כלליות או מסדרת מכונות N2 לסדרת מכונות N4,‏ C4A או C4, האחסון שלכם יועבר מכונן SSD לאחסון Google Cloud Hyperdisk balanced. השדרוג הזה בדרך כלל דורש זמן השבתה מינימלי.

אפשר להתאים אישית את האחסון המאוזן של Google Cloud Hyperdisk לתרחיש השימוש שלכם על ידי הגדרת הפרמטרים הבאים:

• נפח אחסון
• ‫IOPS שהוקצו
• הקצאת משאבים לפי התפוקה שנקבעה

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

שינויים במיקום של יומני בינאריים לצורך PITR

אם מופע של מהדורת Cloud SQL Enterprise מאחסן יומני עסקאות ל-PITR בדיסק, תהליך השדרוג למהדורת Cloud SQL Enterprise Plus מעביר את מיקום האחסון של היומנים האלה ל-Cloud Storage.

התנאים הבאים חלים על שינוי המיקום:

• התהליך נמשך בערך כמו משך הזמן של הגדרת ה-PITR‏ transactionLogRetentionDays עד להשלמת המעבר ל-Cloud Storage.
• אם הגדרתם ערכים לדגל expire_logs_days או binlog_expire_logs_seconds במופע, הערכים האלה יישמרו.
• במהלך המעבר אל Cloud Storage, אי אפשר לשנות את הערכים של הדגלים expire_logs_days או binlog_expire_logs_seconds במופע.
• במהלך המעבר ל-Cloud Storage, מומלץ לא לשנות את הגדרת התצורה של transactionLogRetentionDays PITR. גם אם תגדילו את הערך של transactionLogRetentionDays, יומני ה-binary לא יישמרו בדיסק יותר מ-7 ימים, שהוא ברירת המחדל למופע Cloud SQL Enterprise Edition.

• במהלך המעבר, Cloud SQL שומר יומנים בדיסק רק לערך המינימלי של אחד מהערכים הבאים:
  • הגדרת התצורה של transactionLogRetentionDays PITR מלפני המעבר, שהיא 7 ימים כברירת מחדל.
  • ההגדרות flag‏ expire_logs_days או binlog_expire_logs_seconds שהוגדרו ידנית במופע.
• אחרי המעבר, ב-Cloud SQL נשמרת אותה כמות של יומני ביקורת בינאריים בדיסק שהייתה לפני המעבר, אלא אם הגדרתם את הדגלים expire_logs_days או binlog_expire_logs_seconds במכונה. אם הגדרתם את הדגלים האלה, Cloud SQL ישמור יומני בינאריים בדיסק על סמך הערך המינימלי של הגדרת התצורה transactionLogRetentionDays או הערך של הדגלים.

ברירות המחדל של אחסון גיבויים ויומנים ב-Cloud SQL Enterprise Plus

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

אם הגדרתם את הדגלים expire_logs_days ו-binlog_expire_logs_seconds במופע לפני השדרוג, הערכים שהגדרתם יישארו ללא שינוי.

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

• הגדרת התצורה של transactionLogRetentionDays PITR לפני המעבר, 7 ימים כברירת מחדל
• הדגלים expire_logs_days או binlog_expire_logs_seconds שהוגדרו ידנית במופע

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

אחרי השדרוג למהדורת Cloud SQL Enterprise Plus, תקופת השמירה של יומן העסקאות שמוגדרת כברירת מחדל לכל המכונות המשודרגות תגדל ל-14 ימים. כדי להגדיל את חלון הזמן הזה, או כל חלון זמן אחר שאתם מגדירים לתקופת השמירה של יומן העסקאות, יידרש זמן עד שתגיעו לערך החדש והמוגדל של חלון הזמן המלא לשחזור לנקודת זמן. לדוגמה, אם הערך הישן של ימי השמירה של יומן העסקאות הוא 7, והערך החדש הוגדל ל-14, אז חלון הזמן ל-PITR במשך 7 הימים הראשונים אחרי השדרוג הוא רק 7 ימים. ביום השמיני, חלון ה-PITR יהיה 8 ימים, ביום התשיעי הוא יהיה 9 ימים, עד שחלון השמירה יגדל סופית ל-14 ימים ביום ה-14.

בנוסף, מספר הגיבויים האוטומטיים שמוגדר כברירת מחדל גדל מ-8 ל-15.

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