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

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

סקירה כללית

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

התאוששות מאסון מנוהלת מציעה שתי אפשרויות למעבר לגיבוי: מעבר קשיח לגיבוי ומעבר רך לגיבוי. במעבר גיבוי (failover) קשיח, הרפליקות של ההזמנה ושל מערך הנתונים באזור המשני מקודמות באופן מיידי והופכות לרפליקות הראשיות. הפעולה הזו מתבצעת גם אם האזור הראשי הנוכחי נמצא במצב אופליין, והיא לא ממתינה לשכפול של נתונים שלא שוכפלו. לכן, יכול להיות שיהיה אובדן נתונים במהלך מעבר גיבוי למצב פעיל. ייתכן שיהיה צורך להפעיל מחדש באזור היעד משימות ששמרו נתונים באזור המקור אחרי שהערך של 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), אי אפשר להשתמש במאגר החינמי של משבצות משותפות למשימות טעינה וחילוץ. צריך ליצור הקצאת הזמנה מסוג PIPELINE כי רק מהדורת Enterprise Plus תומכת בכתיבה למערכי נתונים שהוגדרו להתאוששות מאסון.

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

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

• מעבר גיבוי אוטומטי רך מחייב שהאזור הראשי והאזור המשני יהיו זמינים.

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

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

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

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

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

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

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

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

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

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

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

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

מכסה

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

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

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

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

תמחור

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

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

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

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

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

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

התאוששות מאסון מנוהלת תומכת בשינוי גודל דינמי ב-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. ברשימה Secondary location, בוחרים את המיקום המשני.

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. לוחצים על הכרטיסייה Slot reservations (הזמנות למשבצות זמן).

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. לוחצים על הכרטיסייה Slot reservations (הזמנות למשבצות זמן).

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

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

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).
• בייטים של תעבורת נתונים יוצאת מהרשת: נפח הנתונים (בבייטים) שחויב ושוכפל מהאזור הראשי לאזור המשני. המדד הזה עוזר לכם לעקוב אחרי ניצול המכסה של רוחב הפס.

כדי לראות את המדדים האלה בכלי המעקב:

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

   מעבר למעקב

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

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

4. בוחרים באפשרות זמן האחזור של השכפול (bigquery.googleapis.com/storage/replication/dataset_staleness) או באפשרות בייטים של יציאה מהרשת (bigquery.googleapis.com/storage/replication/network_egress_bytes_count).

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

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

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

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: המיקום.

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

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

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

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