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

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

סקירה כללית

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• התצוגה INFORMATION_SCHEMA.RESERVATIONS לא כוללת פרטים על יתירות כשל. כדי להציג רשימה של אירועי יתירות כשל של הזמנות, שולחים שאילתה לתצוגה INFORMATION_SCHEMA.FAILOVER_HISTORY.

• התצוגה 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. מוודאים שיש לכם את ההרשאה bigquery.reservations.update לניהול זהויות והרשאות גישה (IAM) כדי לעדכן את ההזמנות.
2. מוודאים שיש לכם מערכי נתונים קיימים שמוגדרים לרפליקציה. מידע נוסף זמין במאמר שכפול מערך נתונים.

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

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

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

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

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

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

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

מכסה

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

שיקולים לגבי מכסות של הזמנות ליתירות כשל

כשמגדירים תוכנית התאוששות מנוהלת מאסון, יחידות ה-Commitment הבסיסיות להזמנה של יתירות כשל הן יחידות קיבולת מיועדות באזור המשני. המשבצות האלה מופיעות כ "בשימוש" בדף Quotas & System Limits של האזור המשני, גם אם המקום השמור לא פעיל ולא הופעל מעבר חילוץ. חשוב לוודא שבפרויקט הניהול יש מספיק מכסת יחידות קיבולת (Slot) באזור המשני כדי להכיל את קיבולת הבסיס של המקום השמור ליתירות כשל. למידע נוסף על יחידות קיבולת מיועדות ועל השימוש במכסות, קראו את המאמר הסבר על מדדי ה-slot.

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

תמחור

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

   כניסה ל-BigQuery

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

3. לוחצים על Create reservation.

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

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

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

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

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

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

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

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

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

12. אופציונלי: כדי להגדיר את מספר המשימות המקבילות, מעבירים את המתג Override automatic target job concurrency למצב מופעל ומזינים ערך בשדה Target Job Concurrency. פירוט המשבצות מוצג בטבלה Cost estimate. סיכום של שמירת המקום מוצג בטבלה Capacity summary.

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

ההזמנה החדשה מופיעה בכרטיסייה Slot reservations.

SQL

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

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

   כניסה ל-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. ‫לוחצים על Run.

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

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

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

המסוף

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

   כניסה ל-BigQuery

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

3. לוחצים על הכרטיסייה Slot reservations.

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

5. לוחצים על Reservations actions ואז על Edit.

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

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

SQL

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

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

   כניסה ל-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. ‫לוחצים על Run.

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

צירוף של מערך נתונים להזמנה

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

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

המסוף

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

   כניסה ל-BigQuery

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

3. לוחצים על הכרטיסייה Slot reservations.

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

5. לוחצים על הכרטיסייה תוכנית התאוששות מאסון (DR).

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

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

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

SQL

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

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

   כניסה ל-BigQuery

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

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

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

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

3. ‫לוחצים על Run.

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

ניתוק של מערך נתונים מהזמנה

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

המסוף

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

   כניסה ל-BigQuery

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

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

4. לוחצים על הכרטיסייה תוכנית התאוששות מאסון (DR).

5. מרחיבים את האפשרות Actions של הרפליקה הראשית של קבוצת הנתונים.

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

SQL

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

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

   כניסה ל-BigQuery

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

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

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

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

3. ‫לוחצים על Run.

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

הפעלת יתירות כשל

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

המסוף

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

   כניסה ל-BigQuery

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

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

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

5. לוחצים על Failover.

SQL

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

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

   כניסה ל-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. ‫לוחצים על Run.

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

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

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

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

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

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

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

   כניסה ל-BigQuery

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

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

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

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

צפייה בסטטוס הרפליקציה באמצעות Cloud Monitoring

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

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

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

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

   כניסה לדף Monitoring

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

7. אופציונלי: כדי לראות מדדים של מערך נתונים ספציפי או של אזור משני, לוחצים על Add filter, בוחרים באפשרות 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"

השאילתה הבאה מחזירה את המשימות מ-7 הימים האחרונים שהיו נכשלות אם מערכי הנתונים שלהן היו מערכי נתונים של יתירות כשל. כדי לשלוח שאילתות על משימות בארגון, מחליפים את INFORMATION_SCHEMA.JOBS ב-INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION ומשמיטים את jobs.query כי התצוגה INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION לא כוללת טקסט של שאילתה:

SELECT
  jobs.project_id AS job_project_id,
  jobs.job_id,
  jobs.job_type,
  jobs.statement_type,
  jobs.reservation_id,
  jobs.edition,
  jobs.destination_table.project_id AS dataset_project_id,
  jobs.destination_table.dataset_id,
  jobs.destination_table.table_id,
  jobs.query
FROM
  `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.JOBS AS jobs
WHERE
  jobs.creation_time
    BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
    AND CURRENT_TIMESTAMP()
  AND jobs.destination_table.project_id = 'DATASET_PROJECT_ID'
  AND jobs.destination_table.dataset_id = 'DATASET_ID'
  AND (jobs.edition IS NULL OR jobs.edition != 'ENTERPRISE_PLUS');

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

• ‫PROJECT_ID: מזהה הפרויקט שבו בוצעו המשימות.
• ‫LOCATION: המיקום.
• ‫DATASET_PROJECT_ID: מזהה הפרויקט שבו נמצא מערך הנתונים של היעד.
• ‫DATASET_ID: מזהה מערך הנתונים שרוצים לצרף להזמנה לגיבוי במקרה כשל.

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

• מריצים שאילתה ב-INFORMATION_SCHEMA.FAILOVER_HISTORY כדי לראות אירועי יתירות כשל בהזמנות.

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

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