תוכנית התאוששות מאסון (DR) מנוהלת

כדי להגן על הנתונים ולשמור על המשכיות עסקית במהלך הפסקות אזוריות, אתם יכולים להגדיר ולהשתמש בתוכנית התאוששות מאסון (DR) שמנוהלת על ידי BigQuery עבור נתוני BigQuery ועומסי העבודה שלכם.

סקירה כללית

‫BigQuery תומך בתרחישי התאוששות מאסון (DR) במקרה של הפסקת חשמל אזורית. התאוששות מאסון ב-BigQuery מתבססת על שכפול של מערכי נתונים בין אזורים כדי לנהל מעבר לגיבוי במקרה של כשל באחסון. אחרי שיוצרים רפליקה של קבוצת נתונים באזור משני, אפשר לשלוט בהתנהגות יתירות הכשל עבור משאבי מחשוב ואחסון, כדי לשמור על המשכיות עסקית במהלך הפסקת שירות. אחרי יתירות כשל, אפשר לגשת למשאבי מחשוב (יחידות קיבולת) ולמערכי נתונים משוכפלים באזור המקודם. תוכנית התאוששות מאסון (DR) נתמכת רק במהדורת Enterprise Plus.

התאוששות מאסון מנוהלת מציעה שתי אפשרויות למעבר לגיבוי כשל: מעבר לגיבוי כשל קשיח ומעבר לגיבוי כשל רך. במעבר גיבוי אוטומטי קשיח, המערכת מקדמת באופן מיידי את הרפליקות של ההזמנה ומערך הנתונים באזור המשני כדי להפוך אותן לראשיות. הפעולה הזו מתבצעת גם אם האזור הראשי הנוכחי במצב אופליין, והיא לא ממתינה לשכפול של נתונים שלא שוכפלו. לכן, יכול להיות שיהיה אובדן נתונים במהלך מעבר גיבוי למצב פעיל. ייתכן שיהיה צורך להפעיל מחדש באזור היעד משימות ששמרו נתונים באזור המקור אחרי שהערך של replication_time ברפליקה השתנה, לאחר יתירות כשל קשה. במהלך מעבר גיבוי לשחזור מלא, יכול להיות שגם אמצעי הבקרה על הגישה למערכי נתונים (ACL) – כולל תצוגות מורשות והענקת גישה למשתמשים – שלא שוכפלו עדיין יאבדו. כדי למנוע שיבושים בהמשך, כדאי לכלול בתוכניות הגיבוי שלכם שלבים ליצירה מחדש של רשימות ACL (לדוגמה, באמצעות terraform apply). בניגוד למעבר גיבוי אוטומטי קשיח, במעבר גיבוי אוטומטי רך המערכת מחכה עד שכל השינויים בהזמנה ובמערך הנתונים שבוצעו באזור הראשי ישוכפלו לאזור המשני לפני השלמת תהליך מעבר הגיבוי האוטומטי. מעבר יתירות כשל חלק מחייב שהאזור הראשי והאזור המשני יהיו זמינים. הפעלת יתירות כשל רך מגדירה את הערך softFailoverStartTime למקום השמור. השדה softFailoverStartTime מתנקה בסיום של מעבר גיבוי אוטומטי רך.

כדי להפעיל תוכנית התאוששות מאסון (DR), צריך ליצור מקום שמור של מהדורת Enterprise Plus באזור הראשי, שהוא האזור שבו נמצאת קבוצת הנתונים לפני יתירות הכשל. קיבולת מחשוב במצב המתנה באזור המצורף כלולה בהזמנה של Enterprise Plus. לאחר מכן מצרפים מערך נתונים להזמנה הזו כדי להפעיל מעבר לגיבוי במקרה של כשל במערך הנתונים הזה. אפשר לצרף מערך נתונים להזמנה רק אם בוצע מילוי חוסרים במערך הנתונים, ואם יש בו את אותם מיקומים ראשיים ומשניים שמשויכים להזמנה. אחרי שמצרפים מערך נתונים להזמנת מעבר לגיבוי, רק הזמנות Enterprise Plus יכולות לכתוב למערכי הנתונים האלה, ואי אפשר לבצע קידום של שכפול בין אזורים במערך הנתונים. אפשר לקרוא ממערכי נתונים שמצורפים להזמנת מעבר לגיבוי עם כל מודל קיבולת. מידע נוסף על הזמנות זמין במאמר מבוא לניהול עומסי עבודה.

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

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

התרשים הבא מציג את הארכיטקטורה של התאוששות מנוהלת מאסון:

מגבלות

המגבלות הבאות חלות על תוכנית התאוששות מאסון (DR) ב-BigQuery:

• תוכנית התאוששות מאסון (DR) ב-BigQuery כפופה לאותן מגבלות כמו שכפול מערכי נתונים בין אזורים.

• בהזמנת מעבר לגיבוי אפשר לצרף עד 1,000 מערכי נתונים.

• אי אפשר להמיר הזמנה קיימת להזמנה למקרה של כשל אם בהזמנה יש יותר מ-1,000 הקצאות של הזמנות.

• אם שאילתות מפנות למערכי נתונים שמצורפים לכמה הזמנות ליתירות כשל באותו פרויקט ניהול, כל ההזמנות האלה צריכות להשתמש באותו מיקום משני.

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

• במערכי נתונים שמשתמשים בתוכנית התאוששות מאסון (DR), אי אפשר להשתמש במאגר יחידות הקיבולת (Slot) המשותף והחינמי למשימות טעינה וחילוץ. צריך ליצור הקצאת הזמנה מסוג PIPELINE כי רק מהדורת Enterprise Plus תומכת בכתיבה למערכי נתונים שהוגדרו להתאוששות מאסון.

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

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

• יתירות כשל רכה מחייבת שהאזור הראשי והאזור המשני יהיו זמינים.

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

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

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

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

• INFORMATION_SCHEMA.RESERVATIONS לא כולל פרטים על יתירות כשל.

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

מיקומים

האזורים הבאים זמינים כשיוצרים מקום שמור ליתירות כשל:

קוד המיקום	שם האזור	תיאור האזור
AU
	AUSTRALIA-SOUTHEAST1	סידני
	AUSTRALIA-SOUTHEAST2	מלבורן
CA
	NORTHAMERICA-NORTHEAST1	מונטריאול
	NORTHAMERICA-NORTHEAST2	טורונטו
DE
	EUROPE-WEST3	פרנקפורט
	EUROPE-WEST10	ברלין
EU
	EU	האיחוד האירופי, במספר אזורים
	EUROPE-CENTRAL2	ורשה
	EUROPE-NORTH1	פינלנד
	EUROPE-SOUTHWEST1	מדריד
	EUROPE-WEST1	בלגיה
	EUROPE-WEST3	פרנקפורט
	EUROPE-WEST4	הולנד
	EUROPE-WEST8	מילאנו
	EUROPE-WEST9	פריז
IN
	ASIA-SOUTH1	מומבאי
	ASIA-SOUTH2	דלהי
US
	US	ארה"ב, במספר אזורים
	US-CENTRAL1	איווה
	US-EAST1	דרום קרוליינה
	US-EAST4	צפון וירג'יניה
	US-EAST5	קולומבוס
	US-SOUTH1	דאלאס
	US-WEST1	אורגון
	US-WEST2	לוס-אנג׳לס
	US-WEST3	סולט לייק סיטי
	US-WEST4	לאס וגאס

צריך לבחור זוגות של אזורים בתוך AU, CA, DE, EU, IN או US. לדוגמה, אי אפשר לשייך אזור ב-US לאזור ב-EU.

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

• ‫us-central1 – us מספר אזורים
• ‫us-west1 – us מספר אזורים
• ‫eu-west1 – eu מספר אזורים
• ‫eu-west4 – eu מספר אזורים

לפני שמתחילים

1. מוודאים שיש לכם הרשאה לניהול זהויות והרשאות גישה (IAM) bigquery.reservations.update לעדכון הזמנות.
2. מוודאים שיש לכם מערכי נתונים קיימים שהוגדרו לשכפול. מידע נוסף מופיע במאמר בנושא שכפול של מערך נתונים.

רפליקציה בקצב טורבו

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

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

יעד זמן ההתאוששות

יעד משך ההתאוששות (RTO) הוא משך הזמן המקסימלי שמוקצב להתאוששות ב-BigQuery במקרה של אסון. מידע נוסף על RTO זמין במאמר היסודות של תכנון התאוששות מאסון.זמן ה-RTO של התאוששות מאסון מנוהלת הוא חמש דקות אחרי שמתחילים בהעברה אוטומטית לגיבוי (failover). בגלל ה-RTO, הקיבולת זמינה באזור המשני תוך חמש דקות מתחילת תהליך המעבר לגיבוי.

יעד נקודת השחזור

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

מכסה

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

לרפליקציה בקצב טורבו יש מכסת רוחב פס. מידע נוסף מופיע במאמר בנושא מכסות ומגבלות.

תמחור

כדי להגדיר התאוששות מאסון מנוהלת, צריך להשתמש בתוכניות התמחור הבאות:

• קיבולת מחשוב: צריך לרכוש את מהדורת Enterprise Plus.

• רפליקציה בקצב טורבו: תוכנית התאוששות מאסון (DR) מסתמכת על רפליקציה בקצב טורבו במהלך הרפליקציה. החיוב מתבצע על בסיס בייטים פיזיים ועל בסיס גיגה-בייט פיזי משוכפל. מידע נוסף זמין במאמר בנושא תמחור של העברת נתונים לצורך שכפול נתונים: רפליקציה בקצב טורבו.

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

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

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

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

יצירה או שינוי של הזמנה ב-Enterprise Plus

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

לפני שמצרפים קבוצת נתונים למקום שמור, צריך ליצור מקום שמור של Enterprise Plus או לשנות מקום שמור קיים ולהגדיר אותו לתוכנית התאוששות מאסון (DR).

יצירת בקשה לשמירת מקום

צריך לבחור אחת מהאפשרויות האלה:

המסוף

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בתפריט הניווט, לוחצים על Workload management.

3. לוחצים על יצירת בקשה לשמירת מקום.

4. בשדה Reservation name, מזינים שם להזמנה.

5. ברשימה מיקום, בוחרים את המיקום.

6. ברשימה Edition בוחרים במהדורת Enterprise Plus.

7. ברשימה Max reservation size selector, בוחרים את הגודל המקסימלי של ההזמנה.

8. אופציונלי: בשדה Baseline slots, מזינים את מספר המשבצות הבסיסיות להזמנה.

   כדי לקבוע את מספר המשבצות הזמינות להתאמה אוטומטית לעומס, מפחיתים את הערך של Baseline slots מהערך של Max reservation size. לדוגמה, אם יוצרים הזמנה עם 100 משבצות זמן בסיסיות וגודל הזמנה מקסימלי של 400, ההזמנה כוללת 300 משבצות זמן של שינוי גודל אוטומטי. מידע נוסף על משבצות בסיסיות זמין במאמר בנושא שימוש בהזמנות עם משבצות בסיסיות ומשבצות של שינוי גודל אוטומטי.

9. ברשימה מיקום משני, בוחרים את המיקום המשני.

10. כדי להשבית את השיתוף של יחידות קיבולת פנויות ולהשתמש רק בקיבולת יחידות הקיבולת שצוינה, לוחצים על המתג התעלמות מיחידות קיבולת פנויות.

11. כדי להרחיב את הקטע הגדרות מתקדמות, לוחצים על החץ להרחבה .

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

13. לוחצים על Save.

ההזמנה החדשה מופיעה בכרטיסייה הזמנות למשבצות זמן.

SQL

כדי ליצור בקשה לשמירת מקום, משתמשים בהצהרה של CREATE RESERVATION שפת הגדרת נתונים (DDL).

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בעורך השאילתות, מזינים את ההצהרה הבאה:

   CREATE RESERVATION
     `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
   OPTIONS (
     slot_capacity = NUMBER_OF_BASELINE_SLOTS,
     edition = ENTERPRISE_PLUS,
     secondary_location = SECONDARY_LOCATION);

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ADMIN_PROJECT_ID: מזהה הפרויקט של פרויקט הניהול שבבעלותו משאב ההזמנה.
   • ‫LOCATION: המיקום של ההזמנה. אם בוחרים מיקום ב-BigQuery Omni, אפשר לבחור רק במהדורת Enterprise.
   • ‫RESERVATION_NAME: השם של השמירה.

     השם צריך להתחיל ולהסתיים באות קטנה או במספר, ולכלול רק אותיות קטנות, מספרים ומקפים.

   • ‫NUMBER_OF_BASELINE_SLOTS: מספר משבצות הבסיס להקצאה להזמנה. אי אפשר להגדיר את האפשרות slot_capacity ואת האפשרות edition באותה הזמנה.
   • ‫SECONDARY_LOCATION: המיקום המשני של ההזמנה. במקרה של הפסקת חשמל, כל מערכי הנתונים שמצורפים להזמנה הזו יועברו למיקום הזה.

3. לוחצים על הפעלה.

מידע נוסף על הרצת שאילתות זמין במאמר הרצת שאילתה אינטראקטיבית.

שינוי הזמנה קיימת

צריך לבחור אחת מהאפשרויות האלה:

המסוף

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בתפריט הניווט, לוחצים על Workload management.

3. לוחצים על הכרטיסייה הזמנת משבצות זמן.

4. מאתרים את ההזמנה שרוצים לעדכן.

5. לוחצים על פעולות בנושא הזמנות ואז על עריכה.

6. בשדה מיקום משני, מזינים את המיקום המשני.

7. לוחצים על Save.

SQL

כדי להוסיף או לשנות מיקום משני בהזמנה, משתמשים בהצהרת DDL‏ ALTER RESERVATION SET OPTIONS.

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בעורך השאילתות, מזינים את ההצהרה הבאה:

   ALTER RESERVATION
     `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
   SET OPTIONS (
     secondary_location = SECONDARY_LOCATION);

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ADMIN_PROJECT_ID: מזהה הפרויקט של פרויקט הניהול שבבעלותו משאב ההזמנה.
   • ‫LOCATION: המיקום של השמירה, לדוגמה europe-west9.
   • ‫RESERVATION_NAME: השם של השמירה. השם צריך להתחיל ולהסתיים באות קטנה או במספר, ולכלול רק אותיות קטנות, מספרים ומקפים.
   • ‫SECONDARY_LOCATION: המיקום המשני של ההזמנה. במקרה של הפסקת חשמל, כל מערכי הנתונים שמצורפים להזמנה הזו יועברו למיקום הזה.

3. לוחצים על הפעלה.

מידע נוסף על הרצת שאילתות זמין במאמר הרצת שאילתה אינטראקטיבית.

צירוף קבוצת נתונים להזמנה

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

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

המסוף

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בתפריט הניווט, לוחצים על Workload management.

3. לוחצים על הכרטיסייה הזמנת משבצות זמן.

4. לוחצים על ההזמנה שרוצים לצרף אליה קבוצת נתונים.

5. לוחצים על הכרטיסייה שחזור אחרי אסון.

6. לוחצים על הוספת קבוצת נתונים למעבר לגיבוי.

7. מזינים את השם של מערך הנתונים שרוצים לשייך להזמנה.

8. לוחצים על הוספה.

SQL

כדי לצרף קבוצת נתונים להזמנה, משתמשים בהצהרת DDL‏ ALTER SCHEMA SET OPTIONS.

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בעורך השאילתות, מזינים את ההצהרה הבאה:

   ALTER SCHEMA
     `DATASET_NAME`
   SET OPTIONS (
     failover_reservation = ADMIN_PROJECT_ID.RESERVATION_NAME);

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫DATASET_NAME: השם של מערך הנתונים.
   • ‫ADMIN_PROJECT_ID.RESERVATION_NAME: השם של ההזמנה שרוצים לשייך אליה את מערך הנתונים.

3. לוחצים על הפעלה.

מידע נוסף על הרצת שאילתות זמין במאמר הרצת שאילתה אינטראקטיבית.

ניתוק קבוצת נתונים מהזמנה

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

המסוף

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בתפריט הניווט, לוחצים על Workload management ואז על הכרטיסייה Slot reservations.

3. לוחצים על ההזמנה שרוצים לנתק ממנה קבוצת נתונים.

4. לוחצים על הכרטיסייה שחזור אחרי אסון.

5. מרחיבים את האפשרות Actions (פעולות) בשביל העותק הראשי של מערך הנתונים.

6. לוחצים על הסרה.

SQL

כדי לנתק מערך נתונים מהזמנה, משתמשים בהצהרת ALTER SCHEMA SET OPTIONS DDL.

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בעורך השאילתות, מזינים את ההצהרה הבאה:

   ALTER SCHEMA
     `DATASET_NAME`
   SET OPTIONS (
     failover_reservation = NULL);

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫DATASET_NAME: השם של מערך הנתונים.

3. לוחצים על הפעלה.

מידע נוסף על הרצת שאילתות זמין במאמר הרצת שאילתה אינטראקטיבית.

הפעלת מעבר לגיבוי

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

המסוף

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בתפריט הניווט, לוחצים על Disaster recovery (תוכנית התאוששות מאסון (DR)).

3. לוחצים על שם ההזמנה שרוצים לבצע אליה מעבר לגיבוי.

4. בוחרים באפשרות מצב מעבר גיבוי למצב פעיל (ברירת מחדל) או באפשרות מצב מעבר גיבוי למצב פעיל רך.

5. לוחצים על מעבר לגיבוי בענן.

SQL

כדי להוסיף או לשנות מיקום משני בהזמנה, משתמשים בALTER RESERVATION SET OPTIONS הצהרת DDL ומגדירים את is_primary ל-TRUE.

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בעורך השאילתות, מזינים את ההצהרה הבאה:

   ALTER RESERVATION
     `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
   SET OPTIONS (
     is_primary = TRUE, failover_mode=FAILOVER_MODE);

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ADMIN_PROJECT_ID: מזהה הפרויקט של פרויקט הניהול שבבעלותו משאב ההזמנה.
   • ‫LOCATION: המיקום הראשי החדש של ההזמנה, כלומר המיקום המשני הנוכחי לפני המעבר לגיבוי – לדוגמה, europe-west9.
   • ‫RESERVATION_NAME: השם של השמירה. השם צריך להתחיל ולהסתיים באות קטנה או במספר, ולכלול רק אותיות קטנות, מספרים ומקפים.
   • ‫PRIMARY_STATUS: סטטוס בוליאני שמציין אם ההזמנה היא העותק הראשי.
   • ‫FAILOVER_MODE: פרמטר אופציונלי שמשמש לתיאור מצב המעבר לגיבוי. אפשר להגדיר את הערך ל-HARD או ל-SOFT. אם לא מציינים את הפרמטר הזה, המערכת משתמשת בערך HARD כברירת מחדל.

3. לוחצים על הפעלה.

מידע נוסף על הרצת שאילתות זמין במאמר הרצת שאילתה אינטראקטיבית.

מעקב אחרי רפליקציה

אתם יכולים לעקוב אחרי הסטטוס של העתקים של מערכי נתונים באמצעות BigQuery,‏ Cloud Monitoring או תצוגות INFORMATION_SCHEMA.

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

צפייה בסטטוס השכפול באמצעות BigQuery

כדי לראות את סטטוס השכפול ואת זמן האחזור של מערך נתונים במסוףGoogle Cloud :

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בחלונית Explorer מרחיבים את הפרויקט.

3. לוחצים על מערך הנתונים שרוצים לעקוב אחריו.

4. בחלונית הפרטים של מערך הנתונים, לוחצים על הכרטיסייה פרטים.

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

הצגת סטטוס השכפול באמצעות Cloud Monitoring

‫BigQuery מספק את המדדים הבאים ב-Monitoring כדי לעזור לכם לעקוב אחרי סטטוס השכפול:

• השהיית רפליקציה: מידת העדכניות של הנתונים באזור המשני שמשוכפלים כחלק מרפליקציה חוצת-אזורים או מתוכנית התאוששות מאסון מנוהלת. המדד הזה מייצג את היעד להתאוששות מאסון (RPO).
• ‫Network egress bytes: נפח הנתונים (בבייטים) שחויב ושוכפל מהאזור הראשי לאזור המשני. המדד הזה עוזר לכם לעקוב אחרי ניצול המכסה של רוחב הפס.

כדי לראות את המדדים האלה ב-Monitoring:

1. נכנסים לדף Monitoring במסוף Google Cloud .

   מעבר למעקב

2. לוחצים על Metrics Explorer.

3. בשדה בחירת מדד, מחפשים את האפשרות מערך נתונים ב-BigQuery ובוחרים אותה.

4. בוחרים באפשרות Replication latency (bigquery.googleapis.com/storage/replication/dataset_staleness) או באפשרות Network egress bytes (bigquery.googleapis.com/storage/replication/network_egress_bytes_count).

5. לוחצים על אישור.

6. בקטע צבירה, בוחרים שיטת צבירה. למדד זמן האחזור של השכפול, מומלץ לבחור באפשרות 99th percentile (האחוזון ה-99). הצבירה הזו מציגה בצורה טובה יותר את הביצועים במקרה הגרוע ביותר בהשוואה לממוצע או לצבירות אחרות.

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

הצגת סטטוס הרפליקציה באמצעות INFORMATION_SCHEMA

כדי לקבוע את הסטטוס של העותקים, שולחים שאילתה לתצוגה INFORMATION_SCHEMA.SCHEMATA_REPLICAS. לדוגמה:

SELECT
  schema_name,
  replica_name,
  creation_complete,
  replica_primary_assigned,
  replica_primary_assignment_complete
FROM
  `region-LOCATION`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
  schema_name="my_dataset"

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

WITH
  non_epe_reservations AS (
    SELECT project_id, reservation_name
    FROM `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.RESERVATIONS
    WHERE edition != 'ENTERPRISE_PLUS'
  )
SELECT *
FROM
  (
    SELECT job_id
    FROM
      (
        SELECT
          job_id,
          reservation_id,
          ARRAY_CONCAT(referenced_tables, [destination_table]) AS all_referenced_tables,
          query
        FROM
          `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.JOBS
        WHERE
          creation_time
          BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
          AND CURRENT_TIMESTAMP()
      ) A,
      UNNEST(all_referenced_tables) AS referenced_table
  ) jobs
LEFT OUTER JOIN non_epe_reservations
  ON (
    jobs.reservation_id = CONCAT(
      non_epe_reservations.project_id, ':', 'LOCATION', '.', non_epe_reservations.reservation_name))
WHERE
  CONCAT(jobs.project_id, ':', jobs.dataset_id)
  IN UNNEST(
    [
      'PROJECT_ID:DATASET_ID',
      'PROJECT_ID:DATASET_ID']);

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: מזהה הפרויקט.
• ‫DATASET_ID: מזהה קבוצת הנתונים.
• ‫LOCATION: המיקום.

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

• מידע נוסף על שכפול של מערכי נתונים באזורים שונים

• מידע נוסף על מהימנות