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

‫Borderless Lakehouse תומך ברפליקציה בין אזורים ובתוכנית התאוששות מאסון (DR) למטא-נתונים של קטלוגים.

ההגדרה הזו דורשת קטלוגים שמגובים בקטגוריות של Cloud Storage בשני אזורים או במספר אזורים.

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

  1. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

  2. מפעילים את BigLake API, אם הוא עדיין לא מופעל.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לשימוש בנקודת הקצה של קטלוג Iceberg REST בקטלוג הייעודי לזמן ריצה של Lakehouse, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

  • לבצע משימות ניהוליות, כמו ניהול הגישה של המשתמשים לקטלוג, הגישה לאחסון ומצב הפצת פרטי הכניסה של הקטלוג:
  • קריאת נתוני טבלה במצב הפצת פרטי כניסה: BigLake Viewer (roles/biglake.viewer) בפרויקט
  • כתיבת נתוני טבלה במצב של הפצת פרטי כניסה: BigLake Editor (roles/biglake.editor) בפרויקט
  • קריאת משאבים בקטלוג ונתוני טבלאות במצב שאינו הפצת פרטי כניסה:
  • ניהול משאבי קטלוג וכתיבת נתוני טבלה במצב ללא הפצת פרטי כניסה:

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

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

תהליך העבודה של רפליקציה ותוכנית התאוששות מאסון (DR)

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

  1. הצגת סטטוס הרפליקציה: מזהים את האזור הראשי והאזור המשני הנוכחיים כדי לקבוע את אזור היעד ליתירות כשל.
  2. בדיקת סטטוס הסנכרון: בודקים את המצב הנוכחי של האזורים הראשיים והמשניים כדי לוודא שהם מוכנים למעבר.
  3. בחירת מצב יתירות כשל: בוחרים בין יתירות כשל קלה (הכי מתאימה לתחזוקה מתוכננת) לבין יתירות כשל קשה (הכי מתאימה להתאוששות ממקרי חירום).
  4. הפעלת יתירות הכשל: מריצים את הפקודה שמתאימה למצב שבחרתם כדי להחליף בין האזור הראשי לאזור המשני.

הכנה ליתירות כשל

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

הצגת סטטוס הרפליקציה

כדי לזהות את האזורים שבהם הקטלוג משוכפל, מריצים את הפקודה הבאה של gcloud biglake iceberg catalogs describe.

gcloud biglake iceberg catalogs describe CATALOG_NAME

מחליפים את CATALOG_NAME בשם הקטלוג.

בדיקת סטטוס הסנכרון

לפני שמתחילים את מעבר הגיבוי, בודקים את סטטוס הסנכרון של הרפליקה המשנית באמצעות הפקודה gcloud biglake iceberg catalogs failover:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --validate_only \
    --primary-replica PRIMARY_REPLICA_REGION

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

  • ‫CATALOG_NAME: שם הקטלוג.
  • ‫PRIMARY_REPLICA_REGION: האזור שרוצים להגדיר כרפליקה הראשית החדשה.

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

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

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

כדי להתחיל מעבר חלקי למצב כשל, מריצים את הפקודה הבאה ב-gcloud biglake iceberg catalogs failover:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION

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

  • ‫CATALOG_NAME: שם הקטלוג.
  • ‫PRIMARY_REPLICA_REGION: האזור שרוצים להגדיר כרפליקה הראשית החדשה.

יתירות כשל קשיחה

כדי להתחיל מעבר קשיח למצב של יתירות כשל, מריצים את הפקודה הבאה ב-gcloud biglake iceberg catalogs failover:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION \
    --conditional-failover-replication-time=REPLICATION_TIMESTAMP

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

  • ‫CATALOG_NAME: שם הקטלוג.
  • ‫PRIMARY_REPLICA_REGION: האזור שרוצים להגדיר כרפליקה הראשית החדשה.
  • ‫REPLICATION_TIMESTAMP: חותמת זמן בפורמט RFC 3339 שמשמשת כנקודת ביקורת לרפליקציה. תהליך השכפול מוודא שהרפליקה מכילה את כל הנתונים שהוקצו עד לנקודת הזמן הזו. אם הרפליקה לא מכילה את כל הנתונים שנשלחו לפני חותמת הזמן הזו, הפקודה נכשלת. כדי לאלץ את תהליך יתירות הכשל בלי קשר לעיכוב ברפליקציה, מגדירים את חותמת הזמן הזו לתאריך רחוק בעבר. הערה: כשהתכונה הזו נמצאת בגרסת טרום-השקה (Preview), REPLICATION_TIMESTAMP עוקב רק אחרי המטא-נתונים של הקטלוג, ולא אחרי קובצי Cloud Storage. כדי לשמור על אובדן נתונים עם גבול תחתון, קראו את המאמר זמינות ועמידות של נתונים במסמכי התיעוד של Cloud Storage.

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