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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם יוצרים מופע של Cloud SQL Enterprise edition במסוף Cloud de Confiance , האפשרות 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 מאחסנות את יומני הרישום שלהן (write-ahead logs) שמשמשים ל-PITR ב-Cloud Storage. רק מקרים של מהדורת 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, מאחסנים ב-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. הערך יכול להיות בין 1 ל-35 ימים במהדורת Cloud SQL Enterprise Plus, ובין 1 ל-7 ימים במהדורת Cloud SQL Enterprise. אם לא מגדירים ערך לפרמטר הזה, תקופת השמירה של יומן העסקאות היא 14 ימים במופעים של Cloud SQL Enterprise Plus ו-7 ימים במופעים של Cloud SQL Enterprise. מידע נוסף על הגדרת מספר הימים לשמירת יומן העסקאות זמין במאמר הגדרת השמירה של יומן העסקאות.

למרות שמופע מאחסן את יומני הכתיבה מראש שמשמשים ל-PITR ב-Cloud Storage, המופע שומר גם מספר קטן יותר של יומני כתיבה מראש כפולים בדיסק כדי לאפשר שכפול של היומנים ב-Cloud Storage. כברירת מחדל, כשיוצרים מכונה עם PITR מופעל, המכונה מאחסנת את יומני ה-write-ahead שלה ל-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.

מגבלות של PITR

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

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

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

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

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

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

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

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

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

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

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

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

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