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

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

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

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

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

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

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

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

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

  • שחזור למופע חדש
  • שחזור למופע קיים
  • שחזור למופע בפרויקט או באזור אחר

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

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

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

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

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

אם יוצרים מופע של Cloud SQL Enterprise edition במסוף 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 מאחסנות את היומנים הבינאריים שמשמשים ל-PITR ב-Cloud Storage. רק מכונות של מהדורת Cloud SQL Enterprise Plus ששודרגו ממהדורת Cloud SQL Enterprise לפני 1 באפריל 2024, וש-PITR הופעל בהן לפני 11 באוגוסט 2023, ממשיכות לאחסן את היומנים שלהן לצורך PITR בדיסק.

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

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

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

אם המכונה שלכם משתמשת ב-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 למשך הזמן שמוגדר בהגדרת ה-PITR‏ transactionLogRetentionDays. הערך יכול להיות בין יום אחד ל-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), יומני ה-binary מוצפנים באמצעות הגרסה העדכנית ביותר של ה-CMEK. כדי לבצע שחזור, נדרשת הגרסה העדכנית של המפתח לכל הימים שנשמרו כחלק מהפרמטר retained-transaction-log-days.

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

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

כדי לראות כמה נפח בדיסק תופסים יומני ה-binary, בודקים את המדד bytes_used_by_data_type של המופע. הערך של סוג הנתונים binlog מחזיר את הגודל של קובצי ה-binlog בדיסק. במקרים שבהם נשמרים בדיסק יומני עסקאות שמשמשים לשחזור לנקודת זמן (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 שומר יומנים בינאריים בדיסק למשך מספר הימים המינימלי שמוגדר לשמירת יומני העסקאות, או למשך מספר הימים שמוגדר בדגלים. מידע נוסף על האופן שבו יומנים של PITR מאוחסנים אחרי המעבר ועל האופן שבו מפנים מקום בדיסק זמין במאמר יומנים אחרי המעבר ל-Cloud Storage.

מגבלות של PITR

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

  • אתם יכולים להשבית את PITR ולהפעיל אותו מחדש כדי לוודא ש-Cloud SQL מאחסן יומנים ב-Cloud Storage באותו אזור כמו המכונה. עם זאת, 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 (שעון החוף המזרחי). אם זמן השחזור האחרון הוא 15:55 (שעון החוף המזרחי), אפשר לשחזר את המופע עד השעה הזו.

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

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

אחרי שמכונה נמחקת, היומנים של PITR ממשיכים לפעול לפי הגדרות השמירה שהוגדרו למכונה כשהיא הייתה פעילה. תוקף היומנים של PITR פג על בסיס מתגלגל בהתאם להגדרות השמירה אחרי שהמופע נמחק. התקופה הנעה מוגדרת על סמך תקופת השמירה של PITR שהוגדרה במופע לפני המחיקה. לדוגמה, אם הגדרתם את השמירה של PITR במופע של מהדורת Cloud SQL Enterprise Plus ל-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 באזור א' (Bucket11A,‏ Bucket21A ו-Bucket31A). לכל גיבוי יש דלי משלו, ולכן אפשר לשחזר כל גיבוי לאותו מופע שלוש פעמים בכל 30 דקות.
  • לכל גיבוי יש קטגוריה לפרויקט נפרד ולאזור נפרד. לדוגמה, אם יש חמישה פרויקטים באזור מסוים, יהיו חמש קטגוריות לגיבוי הזה באזור הזה, אחת בכל פרויקט. באיור הקודם, יש לנו שני פרויקטים באזור A: פרויקט 1 ופרויקט n.
    • ל-Backup1 יש שני מאגרי טוקנים לפעולות שחזור באזור א'. קטגוריה אחת לפרויקט 1 (Bucket11A) וקטגוריה אחת לפרויקט n (‏Bucket1nA).
    • באופן דומה, ל-Backup3 יש שתי קטגוריות לפעולות שחזור באזור א'. אחד לפרויקט 1 (Bucket31A) ואחד לפרויקט n (Bucket3nA).
  • ל-Backup3 יש קטגוריה אחת באזור B, עבור Project1, כי כל המכונות באותו פרויקט יעד ובאותו אזור יעד חולקות קטגוריה אחת.

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