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

Lakehouse for Apache Iceberg תומך ברפליקציה בין אזורים ובשחזור אחרי אסון למטא-נתונים של קטלוג.

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

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

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

  2. מפעילים את BigLake API.

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    להפעלת ה-API

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

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

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

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

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

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

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

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

הכנות למעבר לגיבוי (failover)

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

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

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

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