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

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

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

ב-31 במאי 2024 השקנו אחסון של יומני טרנזקציות לשחזור לנקודת זמן ב-Cloud Storage. מאז ההשקה הזו, התנאים הבאים חלים:

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

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

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

  • כל המופעים של Cloud SQL במהדורת Enterprise שנוצרו עם PITR מופעל אחרי 31 במאי 2024, מאחסנים יומנים שמשמשים ל-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. הערך הזה יכול להיות בין 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 מופעל, המכונה מאחסנת את יומני העסקאות שלה עבור 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) במופע היעד של Cloud SQL אם יש בו כמה מסדי נתונים עם אותו שם פיזי.

תמונות מצב של מסדי נתונים

אי אפשר להשתמש בתמונות מצב של מסד נתונים של SQL Server במסד נתונים כלשהו במופע שבו מופעל PITR.

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

מודל שחזור מסד נתונים עבור PITR

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

מידע נוסף על מודלים לשחזור של SQL Server זמין במאמרי העזרה של Microsoft.

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

שחזור מופע שנמחק באמצעות 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 במכונה שנמחקה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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