שכפול של מערכי נתונים באזורים שונים

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

סקירה כללית

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

מערכת BigQuery תמיד מאחסנת עותקים של הנתונים בשניCloud de Confiance by S3NS אזורים שונים במיקום של מערך הנתונים. תחום הוא אזור פריסה של משאבי Cloud de Confiance אזור. בכל האזורים, הרפליקציה בין אזורים משתמשת בכתיבה כפולה סינכרונית. בחירה של מיקום במספר אזורים לא מספקת שכפול בין אזורים או יתירות אזורית, ולכן לא חל שיפור בזמינות של מערך הנתונים במקרה של הפסקת חשמל אזורית. הנתונים מאוחסנים באזור אחד בתוך המיקום הגיאוגרפי.

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

שכפול מערך נתונים

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

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

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

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

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

בתרשים הבא מוצגת השכפול שמתרחש כשמבצעים שכפול של מערך נתונים:

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

תמחור

על מערכי נתונים משוכפלים תחויבו על הפעולות הבאות:

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

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

קיבולת מחשוב באזור המשני

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

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

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

שיקולים בקשר למיקום

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

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

דרישות לגבי מיקום משותף

השימוש בשכפול של מערך נתונים תלוי בדרישות הבאות של מיקום משותף.

Cloud Storage

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

מגבלות

השכפול של מערך נתונים ב-BigQuery כפוף למגבלות הבאות:

• הנתונים שמוזרמים ונכתבים בעותק הראשי מ-BigQuery Storage Write API או מהשיטה tabledata.insertAll, ומשוכפלים לעותק המשני, מועברים בשיטת best-effort, ויכול להיות שיהיה עיכוב רב בשכפול.
• הזרמת פעולות עדכון והוספה (upsert) שנכתבות בעותק הראשי מ-Datastream או מ-BigQuery סימון נתונים שהשתנו (CDC) ingestion, שמשוכפלות לאחר מכן בעותק המשני, מתבצעת במאמץ מרבי ויכול להיות שיהיה עיכוב רב בשכפול. אחרי השכפול, פעולות ה-upsert בעותק המשני משולבות בבסיס הנתונים של הטבלה בעותק המשני, בהתאם לערך max_staleness שהוגדר לטבלה.
• אין תמיכה בשכפול בין אזורים לטבלאות שמופעל בהן DML ברמת דיוק גבוהה. המערכת חוסמת יצירה של מערכי נתונים משוכפלים שכבר מכילים טבלאות כאלה, אבל היא לא חוסמת הפעלה של DML עם הרשאות גישה ברמת השורה בטבלאות בתוך מערכי נתונים משוכפלים קיימים. עם זאת, פעולה כזו עלולה לגרום לתוצאות שגויות של שאילתות בטבלה המשנית שבה מופעל DML ברמת הגרנולריות.
• אפשר לנהל שכפול ומעבר באמצעות Cloud de Confiance המסוף או באמצעות הצהרות של שפת הגדרת נתונים (DDL) של SQL.
• אפשר ליצור רק עותק אחד של כל מערך נתונים לכל אזור או לאזור מרובה. אי אפשר ליצור שני עותקים משניים של אותו מערך נתונים באותו אזור יעד.
• המשאבים בתוך העותקים כפופים למגבלות שמתוארות בקטע התנהגות המשאבים.
• תגי מדיניות ומדיניות נתונים משויכת לא משוכפלים לרפליקה המשנית. כל שאילתה שמפנה לעמודות עם תגי מדיניות באזורים שאינם האזור המקורי תיכשל, גם אם השכפול הזה קודם, אלא אם למשתמש יש את התפקיד roles/datacatalog.categoryFineGrainedReader ברמת הפרויקט, התיקייה או הארגון.
• האפשרות 'מסע בזמן' זמינה רק בעותק המשני אחרי שהיצירה של העותק המשני מסתיימת.
• מגבלת הגודל של אזור היעד (בבייטים לוגיים) להפעלת שכפול בין אזורים במערך נתונים היא 10PB עבור us וeu מספר אזורים ו-500TB עבור אזורים אחרים כברירת מחדל. אפשר להגדיר את המגבלות האלה. לקבלת מידע נוסף, אפשר לפנות אל Cloud de Confiance by S3NS התמיכה.
• המכסה חלה על משאבים לוגיים.
• אפשר לשכפל מערך נתונים רק אם יש בו פחות מ-100,000 טבלאות.
• אפשר להוסיף (ואז להסיר) עד 4 רפליקות לאותו אזור לכל מערך נתונים ביום.
• הגורם המגביל הוא רוחב הפס.
• אי אפשר להריץ שאילתות בטבלאות שמוצפנות באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) באזור המשני אם הערך replica_kms_key לא מוגדר.
• אין תמיכה בטבלאות BigLake.
• אי אפשר לשכפל מערכי נתונים חיצוניים או מאוחדים.
• לא ניתן להשתמש במיקומים של BigQuery Omni.
• אם אתם מגדירים שכפול נתונים לצורך תוכנית התאוששות מאסון (DR), אי אפשר להגדיר את זוגות האזורים הבאים:
  • ‫us-central1 – us מספר אזורים
  • ‫us-west1 – us מספר אזורים
  • ‫eu-west1 – eu מספר אזורים
  • ‫eu-west4 – eu מספר אזורים
• אי אפשר לשכפל בקרות גישה ברמת השגרה, אבל אפשר לשכפל בקרות גישה ברמת מערך הנתונים לשגרות.
• ההתנהגות הבאה חלה על מדדי חיפוש:
  • רק המטא-נתונים של אינדקס החיפוש משוכפלים לאזור המשני, ולא נתוני האינדקס עצמם.
  • אם עוברים אל העותק, האינדקס נמחק מהאזור הראשי הקודם ונוצר מחדש באזור המקודם.
  • אם עוברים הלוך ושוב תוך 8 שעות, יצירת האינדקס מתעכבת ב-8 שעות.
• שאילתות מתוזמנות לא מופנות אוטומטית למיקום ראשי חדש אם מקדמים רפליקה משנית. הם נשארים קשורים לאזור שצוין בזמן היצירה שלהם.
  • אם העותק המשוכפל הראשי המקורי הופך לעותק משוכפל משני לקריאה בלבד אחרי הקידום, שאילתות מתוזמנות שמנסות לכתוב נתונים למערך הנתונים ייכשלו.
  • אם האזור הראשי המקורי הופך ללא זמין, השאילתות המתוזמנות נכשלות, גם אם הן מבצעות רק פעולות קריאה.
  • כדי לוודא שהשאילתות המתוזמנות ימשיכו לפעול מול העותק המשני הראשי שקודם, צריך ליצור אותן מחדש באופן ידני במיקום הראשי החדש.
• אי אפשר לשכפל קבוצות נתונים מוסתרות.

התנהגות המשאב

הפעולות הבאות לא נתמכות במשאבים בתוך העותק המשני:

• יצירת שיבוט של טבלה
• יצירת תמונת מצב של טבלה

העותק המשני הוא לקריאה בלבד. אם אתם צריכים ליצור עותק של משאב ברפליקה משנית, אתם צריכים קודם להעתיק את המשאב או לשלוח שאילתה לגבי המשאב, ואז ליצור את התוצאות מחוץ לרפליקה המשנית. לדוגמה, אפשר להשתמש בפקודה CREATE TABLE AS SELECT כדי ליצור משאב חדש ממשאב העותק המשני.

יש הבדלים בין העותקים הראשיים והמשניים:

תרחישי הפסקות זמניות בשירות

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

בטבלה הבאה מוסברת ההשפעה של הפסקות חשמל אזוריות על הנתונים המשוכפלים:

שימוש בשכפול של מערך נתונים

בקטע הזה נסביר איך לשכפל מערך נתונים, לקדם את העותק המשני ולהריץ משימות קריאה ב-BigQuery באזור המשני.

ההרשאות הנדרשות

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

שכפול של מערך נתונים

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

-- Create the primary replica in the us-central1 region.
CREATE SCHEMA my_dataset OPTIONS(location='us-central1');

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `my_replica`
OPTIONS(location='us-east4');

כדי לוודא שהעותק המשני נוצר בהצלחה, אפשר להריץ שאילתה בעמודה creation_complete בתצוגה INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

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

קידום הרפליקה המשנית

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

שימו לב לנקודות הבאות:

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

כדי להגדיר רפליקה כרפליקה הראשית, בוחרים באחת מהאפשרויות הבאות:

ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = 'us-east4');

כדי לוודא שהשדרוג של העותק המשני בוצע בהצלחה, אפשר להריץ שאילתה בעמודה replica_primary_assignment_complete בתצוגה INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

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

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

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

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

The dataset replica of the cross region dataset 'project_id:dataset_id' in region 'REGION' is not yet writable because the primary assignment is not yet complete.

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

מעקב אחר השכפול

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

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

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

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

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

   כניסה ל-BigQuery

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

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

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

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

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

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

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

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

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

   מעבר למעקב

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.

העברת מערכי נתונים

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

שכפול מערך הנתונים

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

-- Create a replica in the secondary region.
ALTER SCHEMA my_migration
ADD REPLICA `eu`
OPTIONS(location='eu');

פעולה זו יוצרת עותק משני בשם eu באזור EU. הרפליקה הראשית היא מערך הנתונים my_migration באזור US עם מספר אזורים.

קידום הרפליקה המשנית

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

ALTER SCHEMA my_migration SET OPTIONS(primary_replica = 'eu')

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

השלמת ההעברה

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

ALTER SCHEMA my_migration
DROP REPLICA IF EXISTS us;

מערך הנתונים נמצא באזור EU, ואין רפליקות של מערך הנתונים my_migration. העברתם בהצלחה את מערך הנתונים לאזור המרובה EU. רשימה מלאה של המשאבים שמועברים זמינה במאמר התנהגות המשאבים.

מפתחות הצפנה בניהול הלקוח (CMEK)

מפתחות של Cloud Key Management Service בניהול הלקוח לא משוכפלים אוטומטית כשיוצרים רפליקה משנית. כדי לשמור על ההצפנה של מערך הנתונים המשוכפל, צריך להגדיר את replica_kms_key למיקום של העותק המשוכפל שנוסף. אפשר להגדיר את replica_kms_key באמצעות הצהרת ה-DDL‏ ALTER SCHEMA ADD REPLICA.

שכפול של מערכי נתונים עם CMEK מתבצע כמו שמתואר בתרחישים הבאים:

• אם קבוצת הנתונים של המקור כוללת default_kms_key, צריך לספק replica_kms_key שנוצר באזור של קבוצת הנתונים המשוכפלת כשמשתמשים בהצהרת ALTER SCHEMA ADD REPLICA DDL.

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

• אם אתם משתמשים ברוטציית מפתחות Cloud KMS ב-default_kms_key או ב-replica_kms_key (או בשניהם), עדיין אפשר להריץ שאילתות במערך הנתונים המשוכפל אחרי רוטציית המפתחות.

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

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

  • מוסיפים ערך default_kms_key למערך הנתונים של המקור.
  • כשיוצרים עותק חדש באמצעות הצהרת ALTER SCHEMA ADD REPLICA DDL, מגדירים ערך לאפשרות replica_kms_key. אפשר להריץ שאילתות בטבלאות CMEK באזור היעד.

  כל טבלאות ה-CMEK באזור היעד משתמשות באותו replica_kms_key, ללא קשר למפתח שבו נעשה שימוש באזור המקור.

יצירת עותק משוכפל עם CMEK

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

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-west1`
OPTIONS(location='us-west1',
  replica_kms_key='my_us_west1_kms_key_name');

מגבלות של CMEK

שכפול של מערכי נתונים עם CMEK כפוף למגבלות הבאות:

• אי אפשר לעדכן את המפתח המשוכפל של Cloud KMS אחרי שנוצר העותק המשוכפל.

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

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

מדיניות בנושא נתונים שהוקצתה לעמודה

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

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

יכולת שינוי

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

התנגשויות בשמות

משאב מדיניות הנתונים זהה באזורים הראשיים והמשניים, למעט המיקום. במדיניות נתונים ובעותק שלה באזורים המשניים, המזהים בפורמט projects/PROJECT_NUMBER/locations/LOCATION_ID/dataPolicies/DATA_POLICY_ID זהים, למעט הערך של LOCATION_ID. השכפול נכשל אם כבר קיימת מדיניות נתונים עם מזהה מתנגש באזור המשני. כדי שהשכפול ימשיך, צריך לפתור את הבעיה של השמות הזהים באזור הראשי או המשני.

מדיניות מותאמת אישית להסתרת נתונים

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

צירוף מדיניות בנושא נתונים לעמודות בטבלה, ניתוק שלה או מחיקה שלה

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

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

הוספת העתק

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

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

• איך עובדים עם הזמנות ב-BigQuery
• מידע נוסף על תכונות האמינות של BigQuery