עדכוני תחזוקה במכונות Cloud SQL

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

סקירה כללית

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

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

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

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

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

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

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

ההשפעה על התחזוקה

ב-Cloud SQL Enterprise Plus, זמן ההשבתה המתוכנן של Cloud SQL הוא כמעט אפס.

בדרך כלל, ב-Cloud SQL מתוזמן אירוע של עדכון תחזוקה אחת לכמה חודשים. עדכון התחזוקה יכול להימשך בין 5 ל-10 דקות לכל מכונה. אם למכונה יש רפליקות לקריאה, יכול להיות שעדכון התחזוקה יימשך יותר זמן. עם זאת, במהלך עדכון התחזוקה, כל מכונה של Cloud SQL Enterprise Edition מאבדת את הקישוריות למשך פחות מ-60 שניות בממוצע. יכול להיות שזמן ההשבתה יהיה ארוך יותר במכונה שמתבצעת בה פעילות רבה במהלך אירוע עדכון התחזוקה, או במכונה עם מערך נתונים גדול מאוד.

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

תחזוקה מתוכננת עם זמן השבתה קרוב לאפס

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

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

דרישות מוקדמות ומגבלות

  • אין תמיכה ברפליקות לקריאה בלבד.

  • צריך להפעיל את הרישום ביומן הבינארי במכונה.

  • אם אתם משתמשים באחד מהדגלים הבאים, אתם צריכים להגדיר אותם לערכי ברירת המחדל:

    • sync_binlog, ערך: 1
    • innodb_flush_log_at_trx_commit, ערך 1
    • replica_skip_errors, ערך OFF
    • binlog_order_commit, ערך ON

    מידע נוסף זמין במאמר הגדרת דגלים לניהול מסדי נתונים.

  • אם אתם משתמשים ב-Cloud SQL Auth Proxy או ב-Cloud SQL Language Connectors, ודאו שהם מעודכנים לגרסה העדכנית.

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

  • מזהה המשתמש של שרת MySQL ישתנה במהלך התחזוקה.

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

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

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

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

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

כדי לדמות אירוע תחזוקה מתוכנן עם זמן השבתה כמעט אפסי, משתמשים בפקודה הבאה ב-ה-CLI של gcloud:

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

מחליפים את INSTANCE_NAME בשם המכונה שבה רוצים להריץ את סימולציה של אירוע תחזוקה.

הגדרות תחזוקה

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

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

  • תזמון התחזוקה (לשעבר סדר העדכון). השבוע שבו מתבצע העדכון של המכונה ב-Cloud SQL. יש לכם כמה אפשרויות:

    • ‫Any: עדכון התחזוקה יכול להתבצע בכל שלב, אבל בדרך כלל הוא מתבצע במהלך השבוע הראשון.
    • Week 1: התחזוקה מתבצעת 7 עד 14 ימים אחרי שנשלחת ההודעה על התחזוקה.
    • ‫Week 2: עדכון התחזוקה מתבצע 15 עד 21 ימים אחרי שליחת ההתראה.
    • ‫Week 5: עדכון התחזוקה מתבצע 35 עד 42 ימים אחרי שליחת ההתראה.

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

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

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

חלונות זמן לתחזוקה שמוגדרים כברירת מחדל

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

  • בימי חול (שני עד שישי): 22:00 עד 06:00
  • חלון סוף השבוע: שישי, 22:00 עד שני, 06:00

דוגמה לתחזוקה

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

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

  • חלון זמן לתחזוקה: ימי ראשון בין 00:00 ל-01:00 (שעון החוף המזרחי)
  • מועד התחזוקה: Week 2
  • פרק זמן לדחיית עדכונים ותחזוקה: מ-1 בנובמבר עד 15 בינואר.

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

התראות על עבודות תחזוקה מתוכננות

אתם יכולים לקבל התראה באימייל על עבודות תחזוקה צפויות לפחות שבוע לפני המועד שנקבע. אם רוצים להגדיר מסנן אימייל להתראות, כותרת האימייל היא Upcoming maintenance for your Cloud SQL instance instancename.

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

ההתראות נשלחות לכתובת האימייל שמשויכת לחשבון Google שלכם. אי אפשר להגדיר כתובת אימייל חלופית בהתאמה אישית (למשל, כתובת אימייל חלופית של צוות).

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

אפשר גם לראות מידע על עבודות תחזוקה קרובות במסוף Google Cloud .

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

  • בדף Logs Explorer במסוף Google Cloud . בתפריט הנפתח All logs name, מחפשים את maintenance-events ולוחצים על Apply. אם נקבעו עבודות תחזוקה למכונה, ביומן מופיעים שם המכונה ושעת ההתחלה של עבודות התחזוקה שנקבעו.

התראות אחרות לגבי פעולות תחזוקה

אם תבחרו לקבל התראות על תחזוקה, תקבלו התראות על אירועים מסוימים:

  • עבודות תחזוקה מתוכננות בקרוב
  • התחלת פעולות תחזוקה
  • עבודות התחזוקה הסתיימו
  • עבודות התחזוקה בוטלו

קביעת מועד חדש לתחזוקה

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

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

לכל שאר המגבלות, ראו מגבלות על תזמון מחדש.

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

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

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

    • חלון הזמינות הבא. האפשרות הזו דוחה את התחזוקה לחלון זמן לתחזוקה הבא שזמין אחרי מועד התחזוקה המתוזמן הנוכחי, בדרך כלל שבוע לאחר מכן.
    • שעה ספציפית. האפשרות הזו מאפשרת לכם לבחור זמן ספציפי לתזמון מחדש, שמוגדר לפי תזמון התחזוקה שהגדרתם למכונה.
      • ‫28 ימים אם בוחרים בתזמון תחזוקה של שבוע 1 או שבוע 2
      • 7 ימים אם בוחרים במועד התחזוקה של שבוע 5

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

איך פועלת התחזוקה

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

בקצרה, אלה השלבים:

  1. מגדירים מכונה וירטואלית מעודכנת עם התוכנה החדשה.
  2. עוצרים את מסד הנתונים ב-VM המקורי.
  3. מעבירים את הדיסק ואת כתובת ה-IP הסטטית למכונה הווירטואלית המעודכנת.
  4. מפעילים את מסד הנתונים ב-VM המעודכן.

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

לפני תחזוקה

לפני התחזוקה, הלקוח מתקשר עם ה-VM המקורי באמצעות כתובת IP סטטית. הנתונים מאוחסנים בדיסק אחסון מתמיד (persistent disk) שמחובר למכונה הווירטואלית המקורית. בדוגמה הזו, למכונה של Cloud SQL מוגדרת זמינות גבוהה, כלומר יש מכונה וירטואלית נוספת במצב המתנה שתחליף אותה במקרה של הפסקה לא מתוכננת. המכונה של Cloud SQL מעבירה תנועה לאפליקציה.

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

שלב 1

מגדירים את המכונה הווירטואלית החדשה.

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

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

תרשים שמראה איך להגדיר את המכונה הווירטואלית

שלב 2

עוצרים את מסד הנתונים ב-VM המקורי.

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

תרשים של המכונה אחרי מעבר למצב של יתירות כשל

שלב 3

עוברים למכונה הווירטואלית המעודכנת.

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

תרשים של מעבר למכונה וירטואלית מעודכנת

שלב 4

מפעילים את מסד הנתונים ב-VM המעודכן.

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

תרשים של הפעלת ה-VM המעודכן

אחרי התחזוקה

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

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

תרשים של אחרי התחזוקה

איך לצמצם את ההשפעה של פעולות התחזוקה

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

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

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

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

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

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

תחזוקה דחופה

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

תחזוקה בשירות עצמי

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

ב-Cloud SQL מתוזמנים עדכוני תחזוקה אחת לכמה חודשים כדי לוודא שמותקנת אצלכם התוכנה העדכנית ביותר, אבל אתם יכולים להשתמש בתחזוקה בשירות עצמי כדי לעדכן את המכונה אם:

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

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

מגבלות תחזוקה

בקטע הזה מתוארות המגבלות של תחזוקת Cloud SQL.

מגבלות על שינוי מועד הפגישה

כמה דברים שחשוב לדעת על שינוי מועד:

  • צריך לתזמן מחדש את התחזוקה לפחות 24 שעות לפני אירוע התחזוקה המתוזמן המקורי.

  • אפשר לשנות את המועד של פעולות התחזוקה במכונה אחת או בכמה מכונות בפרויקט. עם זאת, אפשר לשנות את המועד רק של מופע אחד בכל פעם (אי אפשר לשנות את המועד של כמה מופעים בבת אחת).

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

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

מגבלות על פרק הזמן לדחיית עדכונים ותחזוקה

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

  • החל מ-15 באוגוסט 2025, לא תוכלו להגדיר פרק זמן לדחיית עדכונים ותחזוקה למכונה אם גרסת התחזוקה שלה ישנה יותר מ-12 חודשים. כל מכונה שמשתמשת בגרסת תחזוקה ישנה יותר מ-12 חודשים חייבת לקבל עדכון. כדי למצוא את התאריך של גרסת התחזוקה שמותקנת במכונה, משתמשים בפקודה gcloud sql instances describe או מעיינים בקטע Maintenance בדף Instance overview במסוףGoogle Cloud . למידע נוסף על איתור גרסת התחזוקה של המכונה, ראו הצגת פרטי המכונה. כדי לדעת מה תאריך ההשקה, בודקים את השם של גרסת התחזוקה. לדוגמה, אם השם של גרסת התחזוקה הוא MYSQL_8_0_41.R20250302.00_31, אז תאריך ההשקה שלה הוא 2 במרץ 2025.

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

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

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

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

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

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

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

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

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

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

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

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

שאלות נפוצות בנושא תחזוקה

איך התחזוקה משפיעה על מכונות של יתירות כשל עם זמינות גבוהה (HA) מדור קודם?

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

האם זמן ההשבתה לצורך תחזוקה נכלל ב-SLA?

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

איך עבודות התחזוקה משפיעות על רפליקות לקריאה בלבד?

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

אפשר לבטל עבודות תחזוקה מתוזמנות?

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

מה קורה אם אירוע התחזוקה מבוטל?

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

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

האם התחזוקה של Cloud SQL היא מצטברת?

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

מה קורה אם המכונה נעצרת במהלך עדכון התחזוקה המתוזמן שלה?

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

כמה זמן נמשכת תחזוקה בשירות עצמי לכל הרפליקות לקריאה של מכונה ראשית?

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

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

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

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

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