שדרוג במקום

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

שינויים במיקום של יומני בינאריים עבור 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, מומלץ לא לשנות את הגדרת ה-PITR של transactionLogRetentionDays. גם אם תגדילו את transactionLogRetentionDays, יומני הבינארי לא יישמרו בדיסק יותר מ-7 ימים, שהוא ברירת המחדל למכונה במהדורת Cloud SQL Enterprise.

• במהלך המעבר, Cloud SQL שומר יומנים בדיסק רק לערך המינימלי מבין הערכים הבאים:
  • הגדרת התצורה של transactionLogRetentionDays PITR מלפני המעבר, שהיא 7 ימים כברירת מחדל.
  • ההגדרות של 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 ימים. כדי להגדיל את חלון הזמן הזה, או כל חלון זמן אחר שאתם מגדירים לתקופת השמירה של יומן העסקאות, יידרש זמן של עד הערך החדש והמוגדל כדי להגיע לחלון הזמן המלא של PITR. לדוגמה, אם הערך הישן של ימי השמירה של יומן העסקאות הוא 7 והערך החדש הוגדל ל-14, חלון הזמן ל-PITR במשך 7 הימים הראשונים אחרי השדרוג הוא רק 7 ימים. ביום השמיני, חלון הזמן ל-PITR הופך ל-8 ימים, ביום התשיעי הוא הופך ל-9 ימים, עד שחלון השמירה גדל סופית ל-14 ימים ביום ה-14.

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

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