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

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

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

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

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

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

שחזור באמצעות גיבוי

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

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

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

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

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

שחזור מכונה עם CMEK באמצעות גיבויים משופרים

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

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

  • משתמשים באותו מפתח Cloud KMS כמו במכונה המקורית. זאת התנהגות ברירת המחדל.
  • בוחרים מפתח Cloud KMS אחר למכונת היעד. כדי לבחור מפתח אחר, מגדירים את הדגל --disk-encryption-key בפקודת השחזור.
  • חוזרים ל- Google-owned and Google-managed encryption keys במכונת היעד. כדי להשתמש ב-GMEK, מגדירים את הדגל --clear-disk-encryption בפקודת השחזור.

שחזור מערכת מנקודה מסוימת בזמן (PITR)

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

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

אם יוצרים מכונה של Cloud SQL מהדורת Enterprise במסוף Google Cloud , אז PITR מופעל כברירת מחדל. אם יוצרים מכונה של Cloud SQL ל-MySQL עם זמינות גבוהה, גם PITR מופעל כברירת מחדל. לעומת זאת, אם יוצרים את המכונה באמצעות ה-CLI של gcloud, ‏Terraform או Cloud SQL Admin API, ‏PITR מושבת כברירת מחדל. כדי להפעיל את PITR במכונות האלה, צריך להפעיל אותו ידנית.

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

אחסון יומנים ל-PITR

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

ב-11 באוגוסט 2023 השקנו את האפשרות לאחסן יומני טרנזקציות ל-PITR ב-Cloud Storage. מאז ההשקה, חלים התנאים הבאים:

  • כל המכונות של Cloud SQL Enterprise Plus מאחסנות ב-Cloud Storage את היומנים הבינאריים שמשמשים ל-PITR. רק במכונות של Cloud SQL Enterprise Plus ששדרגתם מ-Cloud SQL מהדורת Enterprise לפני 1 באפריל 2024, ושהפעלתם בהן את PITR לפני 11 באוגוסט 2023, היומנים של PITR ממשיכים להישמר בדיסק.

  • במכונות של Cloud SQL מהדורת Enterprise שנוצרו עם PITR לפני 11 באוגוסט 2023, היומנים של PITR ממשיכים להישמר בדיסק.

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

  • בכל המכונות של Cloud SQL מהדורת Enterprise שיוצרים עם PITR מופעל אחרי 11 באוגוסט 2023, היומנים שמשמשים ל-PITR נשמרים ב-Cloud Storage.

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

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

במכונות שבהן היומנים הבינאריים מאוחסנים רק בדיסק, אתם יכולים להעביר את מיקום האחסון של יומני העסקאות שמשמשים ל-PITR מהדיסק ל-Cloud Storage באמצעות ה-CLI של gcloud או Cloud SQL Admin API. מידע נוסף זמין במאמר העברת האחסון של יומן העסקאות ל-Cloud Storage.

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

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

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

תקופת השמירה של היומנים

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

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

ביומנים בינאריים של PITR שמאוחסנים בדיסק, שמועברים ל-Cloud Storage או שכבר הועברו ל-Cloud Storage, ‏Cloud SQL שומר את היומנים למשך הערך המינימלי שמוגדר באחת מההגדרות הבאות:

  • הגדרת הגיבוי של transactionLogRetentionDays
  • הדגל expire_logs_days או הדגל binlog_expire_logs_seconds

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

  • הגדרת תצורה של transactionLogRetentionDays
  • דגל לניהול מסד נתונים expire_logs_days
  • דגל לניהול מסד נתונים binlog_expire_logs_seconds

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

במכונות שמופעלים בהן מפתחות הצפנה בניהול הלקוח (CMEK), היומנים הבינאריים מוצפנים באמצעות הגרסה העדכנית של ה-CMEK. כדי לבצע שחזור, נדרשת גרסת המפתח העדכנית ביותר לכל הימים שנשמרו כחלק מהפרמטר retained-transaction-log-days.

יומנים ושימוש בדיסק

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

כדי לבדוק כמה נפח דיסק מנוצל על ידי היומנים הבינאריים, בודקים את המדד bytes_used_by_data_type של המכונה. הערך של סוג הנתונים binlog מחזיר את גודל ה-binlogs בדיסק. במכונות שבהן יומני העסקאות שמשמשים ל-PITR מאוחסנים בדיסק, Cloud SQL מוחק נתונים מהדיסק מדי יום כדי לעמוד בהגדרה של transactionLogRetentionDays ל-PITR, כפי שמתואר בקטע שמירה אוטומטית של גיבויים ויומני עסקאות. עם זאת, אם מגדירים את הדגל expire_logs_days או binlog_expire_logs_seconds לערך נמוך יותר ממספר הימים לשמירת יומן העסקאות, Cloud SQL יכול למחוק את היומנים הבינאריים מוקדם יותר.

אם הגודל של היומנים הבינאריים גורם לבעיה במכונה:

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

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

מגבלות של PITR

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

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

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

    לדוגמה, אם מציינים 7 בתור הערך של הפרמטר transactionLogRetentionDays, אז בפרמטר backupRetentionSettings מגדירים את מספר הretainedBackups ל-8.

הוראות מפורטות לביצוע PITR מופיעות במאמר [שימוש בשחזור מערכת מנקודה מסוימת בזמן (PITR)][perform-pitr].

שחזור של מכונה לא זמינה

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

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

נניח שמכונה של Cloud SQL לא זמינה בשעה 16:00 (שעון EST). אם זמן השחזור האחרון הוא בשעה 15:55 (שעון EST), תוכלו לשחזר את המכונה עד לשעה הזו.

שחזור מכונה שנמחקה באמצעות PITR

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

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

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

  • instance_deletion_time
  • log_retention_days

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

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

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

דרישות לשחזור למכונה חדשה

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

  • גרסת מסד הנתונים של מכונת היעד צריכה להיות זהה לגרסה של המכונה שממנה בוצע הגיבוי.

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

  • מכונת היעד חייבת להיות במצב RUNNABLE.

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

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

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

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

איך פועלים אסימונים

לדוגמה, בתרשים הבא, Backup1,‏ Backup2 ו-Backup3 הם הגיבויים מאותו מכונה של מקור.

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

  • לכל גיבוי (Backup1,‏ Backup2 ו-Backup3) יש קטגוריה משלו של אסימונים לפעולות שחזור שמטרגטות מכונות שונות בפרויקט 1 באזור A (קטגוריה Bucket11A,‏ Bucket21A ו-Bucket31A). לכל גיבוי יש קטגוריה משלו, ולכן אפשר לשחזר כל גיבוי לאותו מכונה שלוש פעמים בכל שלושים דקות.
  • לכל גיבוי יש קטגוריה לפרויקט נפרד ולאזור נפרד. לדוגמה, אם יש חמישה פרויקטים באזור, יש חמש קטגוריות לגיבוי הזה באזור, אחת בכל פרויקט. באיור הקודם, יש לנו שני פרויקטים באזור A: פרויקט 1 ופרויקט n.
    • ל-Backup1 יש שני מאגרי אסימונים לפעולות שחזור באזור א'. קטגוריה אחת לפרויקט 1 (Bucket11A) וקטגוריה אחת לפרויקט n‏ (Bucket1nA).
    • באופן דומה, ל-Backup3 יש שתי קטגוריות לפעולות שחזור באזור א'. אחד לפרויקט 1 (Bucket31A) ואחד לפרויקט n‏ (Bucket3nA).
  • ל-Backup3 יש קטגוריה אחת באזור ב', עבור Project1, כי כל המכונות באותו פרויקט יעד ובאותו אזור יעד חולקות קטגוריה אחת.

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