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

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

התצורה הזו דורשת קטלוגים שמגובים על ידי קטגוריות של 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)

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

הפעלת מעבר לגיבוי

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

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