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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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