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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • מכונות של Cloud SQL במהדורת Enterprise שנוצרו עם PITR לפני 9 בינואר 2023 ממשיכות לאחסן את היומנים שלהן לצורך PITR בדיסק.

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

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

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

במקרה של יומני PITR write-ahead שנשמרים בדיסק, שנמצאים בתהליך של מעבר ל-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.

מגבלות של PITR

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

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

הוראות מפורטות לביצוע 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, כי כל המכונות באותו פרויקט יעד ובאותו אזור יעד חולקות קטגוריה אחת.

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