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

באמצעות שכפול של מערכי נתונים ב-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, ואז משוכפלים לרפליקה המשנית, מתבצעת בשיטת 'המאמץ הכי טוב' ויכול להיות שיהיה עיכוב רב בשכפול.
• סטרימינג של פעולות עדכון והוספה (upsert) שנכתבות בעותק הראשי מ-Datastream או מ-BigQuery סימון נתונים שהשתנו (CDC) ingestion, שמשוכפלות לאחר מכן בעותק המשני, מתבצע על בסיס מאמץ מרבי, ויכול להיות שיהיה עיכוב רב בשכפול. אחרי השכפול, פעולות ה-upsert בעותק המשני מוזגו עם בסיס הנתונים של הטבלה בעותק המשני, בהתאם לערך max_staleness שהוגדר בטבלה.
• אי אפשר להפעיל DML ברמת גרנולריות גבוהה בטבלה במערך נתונים משוכפל, ואי אפשר לשכפל מערך נתונים שמכיל טבלה שמופעל בה DML ברמת גרנולריות גבוהה.
• השכפול והמעבר מניהול באמצעות הצהרות של שפת הגדרת נתונים (DDL) ב-SQL.
• אפשר ליצור רק רפליקה אחת של כל קבוצת נתונים לכל אזור או במספר אזורים. אי אפשר ליצור שני עותקים משניים של אותו מערך נתונים באותו אזור יעד.
• המשאבים ברפליקות כפופים להגבלות שמתוארות במאמר בנושא התנהגות משאבים.
• תגי מדיניות ומדיניות נתונים משויכת לא משוכפלים בעותק המשני. כל שאילתה שמפנה לעמודות עם תגי מדיניות באזורים אחרים מלבד האזור המקורי תיכשל, גם אם הרפליקה הזו קודמה.
• האפשרות Time travel זמינה רק ברפליקה המשנית אחרי שהיצירה של הרפליקה המשנית מסתיימת.
• מגבלת הגודל של אזור היעד (בבייטים לוגיים) להפעלת שכפול בין אזורים במערך נתונים היא 10PB עבור us וeu מספר אזורים ו-500TB עבור אזורים אחרים כברירת מחדל. אפשר להגדיר את המגבלות האלה. לקבלת מידע נוסף, אפשר לפנות אל Cloud de Confiance by S3NS התמיכה.
• המכסה חלה על משאבים לוגיים.
• אפשר לשכפל מערך נתונים רק אם יש בו פחות מ-100,000 טבלאות.
• יש מגבלה של 4 רפליקות לכל היותר שאפשר להוסיף (ואז להסיר) לאותו אזור לכל מערך נתונים ביום.
• הבעיה היא רוחב פס.
• אי אפשר להריץ שאילתות בטבלאות שמוצפנות באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) באזור המשני אם הערך replica_kms_key לא מוגדר.
• אין תמיכה בטבלאות BigLake.
• אי אפשר לשכפל מערכי נתונים חיצוניים או מאוחדים.
• לא ניתן להשתמש במיקומים של BigQuery Omni.
• אם אתם מגדירים שכפול נתונים לצורך התאוששות מאסון, אי אפשר להגדיר את זוגות האזורים הבאים:
  • ‫us-central1 – us מספר אזורים
  • ‫us-west1 – us מספר אזורים
  • ‫eu-west1 – eu מספר אזורים
  • ‫eu-west4 – eu מספר אזורים
• אי אפשר לשכפל אמצעי בקרה לגישה ברמת התרחיש, אבל אפשר לשכפל אמצעי בקרה לגישה ברמת מערך הנתונים לתרחישים.
• ההתנהגות הבאה חלה על אינדקסים של חיפוש:
  • רק המטא-נתונים של אינדקס החיפוש משוכפלים לאזור המשני, ולא נתוני האינדקס עצמם.
  • אם עוברים לשימוש ברפליקה, האינדקס נמחק מהאזור הראשי הקודם ונוצר מחדש באזור המקודם.
  • אם עוברים הלוך ושוב תוך 8 שעות, יצירת האינדקס מתעכבת ב-8 שעות.
• אי אפשר לשכפל קבוצות נתונים מוסתרות.

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לשכפל מערך נתונים, משתמשים בהצהרת ה-DDL‏ ALTER SCHEMA ADD REPLICA.

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

בדוגמה הבאה נוצר מערך נתונים בשם my_dataset באזור us-central1, ואז נוספת רפליקה באזור us-east4:

-- 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 SET OPTIONS DDL ומגדירים את האפשרות primary_replica.

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

בדוגמה הבאה, הus-east4 רפליקה מקודמת להיות הראשית:

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

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

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

כדי להסיר רפליקה ולהפסיק את השכפול של מערך הנתונים, משתמשים בהצהרת ALTER SCHEMA DROP REPLICA DDL.

בדוגמה הבאה, הרפליקה us מוסרת:

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

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

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

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

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

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

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

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

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

העתקת פריט

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

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

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