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

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

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

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