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

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

ההגדרה הזו דורשת קטלוגים שמגובים על ידי קטגוריות של Cloud Storage Dual-Region או Multi-Region.

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

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

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

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

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

   להפעלת ה-API

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

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

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

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

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

תהליך העבודה של השכפול ותוכנית ההתאוששות מאסון (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 CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION

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

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

• שימוש בקטלוג Iceberg REST של Lakehouse runtime