פריסת אוטומציה של גיבויים ב-BigQuery שאפשר להרחיב

Last reviewed 2024-09-17 UTC

במאמר הזה מוסבר איך פורסים את האוטומציה של גיבוי BigQuery שניתנת להרחבה.

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

ארכיטקטורה

התרשים הבא מציג את ארכיטקטורת הגיבוי האוטומטי:

ההפעלה מופעלת על ידי Cloud Scheduler. שירות השליחה, באמצעות BigQuery API, מציג את הטבלאות שכלולות בהיקף. באמצעות הודעת Pub/Sub, שירות השליחה שולח בקשה אחת לכל טבלה לשירות ההגדרה. שירות ההגדרה קובע את מדיניות הגיבוי של הטבלאות, ואז שולח בקשה אחת לכל טבלה לשירות Cloud Run הרלוונטי. לאחר מכן, שירות Cloud Run שולח בקשה ל-BigQuery API ומריץ את פעולות הגיבוי. ‫Pub/Sub מפעיל את שירות התיוג, שמתעד את התוצאות ומעדכן את מצב הגיבוי בשכבת המטא-נתונים של Cloud Storage.

פרטים על הארכיטקטורה זמינים במאמר Scalable BigQuery backup automation.

מטרות

• פיתוח שירותי Cloud Run.
• הגדרת משתני Terraform.
• מריצים את הסקריפטים של Terraform ושל הפריסה הידנית.
• מפעילים את הפתרון.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• BigQuery
• Pub/Sub
• Cloud Logging
• Cloud Run
• Cloud Storage
• Cloud Scheduler
• Firestore in Datastore mode (Datastore)

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

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

בקטע הזה, יוצרים משאבים חד-פעמיים.

1. במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

2. אם רוצים ליצור פרויקט חדש Google Cloud לשימוש כפרויקט המארח לפריסה, משתמשים בפקודה gcloud projects create:

      gcloud projects create PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה הפרויקט שרוצים ליצור.

3. מתקינים את Maven:

   1. מורידים את Maven.

   2. ב-Cloud Shell, מוסיפים את Maven ל-PATH:

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
      

4. משכפלים את מאגר GitHub ב-Cloud Shell:

   git clone https://github.com/GoogleCloudPlatform/bq-backup-manager.git
   

5. מגדירים ומייצאים את משתני הסביבה הבאים:

   export PROJECT_ID=PROJECT_ID
   export TF_SA=bq-backup-mgr-terraform
   export COMPUTE_REGION=COMPUTE_REGION
   export DATA_REGION=DATA_REGION
   export BUCKET_NAME=${PROJECT_ID}-bq-backup-mgr
   export BUCKET=gs://${BUCKET_NAME}
   export DOCKER_REPO_NAME=docker-repo
   export CONFIG=bq-backup-manager
   export ACCOUNT=ACCOUNT_EMAIL
   
   gcloud config configurations create $CONFIG
   gcloud config set project $PROJECT_ID
   gcloud config set account $ACCOUNT
   gcloud config set compute/region $COMPUTE_REGION
   
   gcloud auth login
   gcloud auth application-default login
   

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

   • ‫PROJECT_ID: המזהה של Google Cloud פרויקט המארח Google Cloud שבו רוצים לפרוס את הפתרון.
   • ‫COMPUTE_REGION: Google Cloud האזור שבו רוצים לפרוס משאבי מחשוב כמו Cloud Run וניהול זהויות והרשאות גישה (IAM).
   • ‫DATA_REGION: האזור Google Cloud שבו רוצים לפרוס משאבי נתונים (כמו קטגוריות ומערכי נתונים).
   • ACCOUNT_EMAIL: כתובת האימייל בחשבון המשתמש.

6. מפעילים את ממשקי ה-API:

   ./scripts/enable_gcp_apis.sh
   

   הסקריפט מפעיל את ממשקי ה-API הבאים:

   • Cloud Resource Manager API
   • IAM API
   • Data Catalog API
   • Artifact Registry API
   • BigQuery API
   • Pub/Sub API
   • Cloud Storage API
   • Cloud Run Admin API
   • Cloud Build API
   • Service Usage API
   • App Engine Admin API
   • Serverless VPC Access API
   • Cloud DNS API

7. מכינים את קטגוריית מצב Terraform:

   gcloud storage buckets create $BUCKET --project=$PROJECT_ID --location=$COMPUTE_REGION --uniform-bucket-level-access
   

8. מכינים את חשבון השירות של Terraform:

   ./scripts/prepare_terraform_service_account.sh
   

9. כדי לפרסם תמונות שהפתרון הזה משתמש בהן, צריך להכין מאגר Docker:

   gcloud artifacts repositories create $DOCKER_REPO_NAME
     --repository-format=docker \
     --location=$COMPUTE_REGION \
     --description="Docker repository for backups"
   

פריסת התשתית

חשוב לוודא שביצעתם את השלבים שבקטע לפני שמתחילים לפחות פעם אחת.

בקטע הזה מוסבר איך לפרוס או לפרוס מחדש את בסיס הקוד העדכני ביותר בסביבת Google Cloud .

הפעלת ההגדרות האישיות ב-CLI של gcloud

• ב-Cloud Shell, מפעילים ומאמתים את ההגדרה של ה-CLI של gcloud:

  gcloud config configurations activate $CONFIG
  
  gcloud auth login
  gcloud auth application-default login
  

יצירת תמונות של שירותי Cloud Run

• ב-Cloud Shell, יוצרים ופורסים קובצי אימג' של Docker לשימוש בשירות Cloud Run:

  export DISPATCHER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest
  export CONFIGURATOR_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest
  export SNAPSHOTER_BQ_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest
  export SNAPSHOTER_GCS_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest
  export TAGGER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest
  
  ./scripts/deploy_services.sh
  

הגדרת משתני Terraform

הפריסה הזו משתמשת ב-Terraform להגדרות ובסקריפט פריסה.

1. ב-Cloud Shell, יוצרים קובץ TFVARS חדש של Terraform שבו אפשר לשנות את המשתנים שבקטע הזה:

   export VARS=FILENAME
   .tfvars
   

   מחליפים את FILENAME בשם של קובץ המשתנים שיצרתם (לדוגמה, my-variables). אפשר להשתמש בקובץ example-variables כהפניה.

2. בקבצים מסוג TFVARS, מגדירים את משתני הפרויקט:

   project = "PROJECT_ID"
   compute_region = "COMPUTE_REGION"
   data_region = "DATA_REGION"
   

   אפשר להשתמש בערכי ברירת המחדל שמוגדרים בקובץ variables.tf או לשנות את הערכים.

3. מגדירים את חשבון השירות של Terraform שיצרתם והכנתם קודם בקטע לפני שמתחילים:

   terraform_service_account =
   "bq-backup-mgr-terraform@PROJECT_ID.iam.gserviceaccount.com"
   

   חשוב להשתמש בכתובת האימייל המלאה של החשבון שיצרתם.

4. מגדירים את שירותי Cloud Run כך שישתמשו בתמונות הקונטיינר שיצרתם ופרסתם קודם:

   dispatcher_service_image     = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest"
   configurator_service_image   = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest"
   snapshoter_bq_service_image  = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest"
   snapshoter_gcs_service_image = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest"
   tagger_service_image         = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest"
   

   הסקריפט הזה מורה ל-Terraform להשתמש בתמונות שפורסמו בשירותי Cloud Run, ש-Terraform יוצר בהמשך.

   ‫Terraform מקשר רק שירות Cloud Run לתמונה קיימת. הוא לא יוצר את התמונות מבסיס הקוד, כי הפעולה הזו הושלמה בשלב הקודם.

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

   {
   name    = "SCHEDULER_NAME"
   cron    = "SCHEDULER_CRON"
   payload = {
       is_force_run = FORCE_RUN
       is_dry_run   = DRY_RUN
   
       folders_include_list  = [FOLDERS_INCLUDED]
       projects_include_list = [PROJECTS_INCLUDED]
       projects_exclude_list = [PROJECTS_EXCLUDED]
       datasets_include_list =  [DATASETS_INCLUDED]
       datasets_exclude_list =  [DATASETS_EXCLUDED]
       tables_include_list   =  [TABLES_INCLUDED]
       tables_exclude_list   =  [TABLES_EXCLUDED]
       }
   }
   

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

   • ‫SCHEDULER_NAME: השם המוצג של Cloud Scheduler.
   • ‫SCHEDULER_CRON: התדירות שבה הכלי לתזמון בודק אם הגיע הזמן לגבות את הטבלאות שכלולות בהיקף, על סמך לוחות הזמנים האישיים שלהן לגיבוי. אפשר להשתמש בכל מחרוזת שמתאימה ל-unix-cron. לדוגמה, 0 * * * * היא תדירות שעתית.
   • ‫FORCE_RUN: ערך בוליאני. מגדירים את הערך false אם רוצים שהכלי לתזמון ישתמש בלוחות הזמנים של cron של הטבלאות. אם ההגדרה היא true, כל הטבלאות שכלולות בהיקף מגובות, ללא קשר להגדרת ה-cron שלהן.
   • ‫DRY_RUN: ערך בוליאני. אם הערך הוא true, לא מתבצעות פעולות גיבוי בפועל. רק הודעות יומן נוצרות. משתמשים באפשרות הזו trueכשרוצים לבדוק את הפתרון ולנפות בו באגים בלי לשלם על גיבויים.
   • ‫FOLDERS_INCLUDED: רשימה של מזהים מספריים של תיקיות שמכילות נתונים ב-BigQuery (לדוגמה, 1234, 456). כשמגדירים את האפשרות הזו, הפתרון מגבה את הטבלאות בתיקיות שצוינו ומתעלם מההגדרות של השדות projects_include_list, datasets_include_list ו-tables_include_list.
   • ‫PROJECTS_INCLUDED: רשימה של שמות פרויקטים (לדוגמה, "project1", "project2"). אם ההגדרה הזו מוגדרת, הפתרון מגבה את הטבלאות בפרויקטים שצוינו ומתעלם מהגדרות השדות datasets_include_list ו-tables_include_list. המערכת מתעלמת מההגדרה הזו אם מגדירים את השדה folders_include_list.
   • ‫PROJECTS_EXCLUDED: רשימה של שמות פרויקטים או ביטוי רגולרי (לדוגמה, "project1", "regex:^test_"). אם מגדירים את הפרמטר הזה, הפתרון לא יוצר גיבויים של הטבלאות בפרויקטים שצוינו. אפשר להשתמש בהגדרה הזו בשילוב עם השדה folders_include_list.
   • ‫DATASETS_INCLUDED: רשימה של מערכי נתונים (לדוגמה, "project1.dataset1", "project1.dataset2"). אם המאפיין הזה מוגדר, הפתרון מגבה את הטבלאות במערכי הנתונים שצוינו ומתעלם מההגדרה של השדה tables_include_list. המערכת מתעלמת מההגדרה הזו אם מגדירים את השדות folders_include_list או projects_include_list.
   • ‫DATASETS_EXCLUDED: רשימה של מערכי נתונים או ביטוי רגולרי (לדוגמה, "project1.dataset1", "regex:.*\\_landing$"). אם ההגדרה הזו מוגדרת, הפתרון לא יוצר גיבויים של הטבלאות במערכי הנתונים שצוינו. אפשר להשתמש בהגדרה הזו בשילוב עם השדות folders_include_list או projects_include_list.
   • ‫TABLES_INCLUDED: רשימה של טבלאות (לדוגמה, "project1.dataset1.table 1", "project1.dataset2.table2"). אם ההגדרה הזו מוגדרת, הפתרון מגבה את הטבלאות שצוינו. המערכת מתעלמת מההגדרה הזו אם מגדירים את השדות folders_include_list, ‏projects_include_list או datasets_include_list.
   • ‫TABLES_EXCLUDED: רשימה של טבלאות או ביטוי רגולרי (לדוגמה, "project1.dataset1.table 1", "regex:.*\_test"). אם ההגדרה הזו מוגדרת, הפתרון לא מגבה את הטבלאות שצוינו. אפשר להשתמש בהגדרה הזו בשילוב עם השדות folders_include_list, projects_include_list או datasets_include_list.

   כל רשימות ההחרגות מקבלות ביטויים רגולריים בפורמט regex:REGULAR_EXPRESSION.

   אם השם המוגדר במלואו של הרשומה (לדוגמה, "project.dataset.table") תואם לביטוי רגולרי כלשהו שסופק, הרשומה לא תיכלל בהיקף הגיבוי.

   הנה כמה תרחישי שימוש נפוצים:

   • החרגה של כל שמות מערכי הנתונים שמסתיימים ב-_landing: datasets_exclude_list = ["regex:.*\\_landing$"]
   • לא כולל את כל הטבלאות שמסתיימות ב-_test, ב-_tst, ב-_bkp או ב-_copy: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

הגדרת מדיניות חלופית

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

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

יש עוד קבוצות של שדות מדיניות, בהתאם לשיטת הגיבוי שבה תבחרו להשתמש: תמונות מצב של BigQuery, ייצוא ל-Cloud Storage או שניהם.

1. בקובץ TFVARS, בשביל המשתנה default_policy, מגדירים את השדות הנפוצים הבאים למדיניות ברירת המחדל:

   fallback_policy = {
     "default_policy" : {
       "backup_cron" : "BACKUP_CRON"
       "backup_method" : "BACKUP_METHOD",
       "backup_time_travel_offset_days" : "OFFSET_DAYS",
       "backup_storage_project" : "BACKUP_STORAGE_PROJECT",
       "backup_operation_project" : "BACKUP_OPERATIONS_PROJECT",
   
   

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

   • ‫BACKUP_CRON: ביטוי cron להגדרת התדירות שבה הטבלה מגובה (לדוגמה, כדי לגבות כל 6 שעות, מציינים 0 0 */6 * * *). הביטוי צריך להיות תואם ל-Spring-Framework.
   • ‫BACKUP_METHOD: ה-method, שאתם מציינים כ-BigQuery Snapshot,‏ GCS Snapshot (כדי להשתמש ב-method של ייצוא ל-Cloud Storage) או Both. בהמשך מוסבר אילו שדות חובה צריך למלא לכל שיטת גיבוי שתבחרו.
   • OFFSET_DAYS: מספר הימים בעבר שקובע את נקודת הזמן שממנה יגובו הטבלאות. הערכים יכולים להיות מספר בין 0 ל-7.
   • ‫BACKUP_STORAGE_PROJECT: מזהה הפרויקט שבו מאוחסנות כל הפעולות של יצירת תמונת מצב וייצוא. זה אותו פרויקט שבו נמצאים bq_snapshot_storage_dataset ו-gcs_snapshot_storage_location. בפריסות קטנות אפשר להשתמש בפרויקט המארח, אבל בפריסות בקנה מידה גדול כדאי להשתמש בפרויקט נפרד.
   • ‫BACKUP_OPERATIONS_PROJECT: הגדרה אופציונלית שבה מציינים את מזהה הפרויקט שבו יפעלו כל הפעולות של יצירת תמונת מצב וייצוא. המכסות והמגבלות של צילומי מצב ושל משימות ייצוא חלות על הפרויקט הזה. הערך כאן יכול להיות זהה לערך של backup_storage_project. אם לא מגדירים את המדיניות, הפתרון משתמש בפרויקט של טבלת המקור.

2. אם ציינתם BigQuery Snapshot או Both כbackup_method, מוסיפים את השדות הבאים אחרי השדות המשותפים, במשתנה default_policy:

     "bq_snapshot_expiration_days" : "SNAPSHOT_EXPIRATION",
     "bq_snapshot_storage_dataset" : "DATASET_NAME",
   

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

   • ‫SNAPSHOT_EXPIRATION: מספר הימים שבהם כל תמונת מצב תישמר (לדוגמה, 15).
   • ‫DATASET_NAME: השם של מערך הנתונים שבו יישמרו תמונות המצב (לדוגמה, backups). מערך הנתונים צריך כבר להתקיים בפרויקט שצוין ב-backup_storage_project.

3. אם ציינתם GCS Snapshot (כדי להשתמש בשיטת הייצוא ל-Cloud Storage) או Both כ-backup_method, מוסיפים את השדות הבאים למשתנה default_policy:

     "gcs_snapshot_storage_location" : "STORAGE_BUCKET",
     "gcs_snapshot_format" : "FILE_FORMAT",
     "gcs_avro_use_logical_types" : AVRO_TYPE,
     "gcs_csv_delimiter" : "CSV_DELIMITER",
     "gcs_csv_export_header" : CSV_EXPORT_HEADER
   

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

   • ‫STORAGE_BUCKET: קטגוריית Cloud Storage שבה רוצים לאחסן את הנתונים המיוצאים, בפורמט gs://bucket/path/. לדוגמה: gs://bucket1/backups/.
   • ‫FILE_FORMAT: פורמט הקובץ והדחיסה שמשמשים לייצוא טבלה ב-BigQuery ל-Cloud Storage. הערכים הזמינים הם CSV,‏ CSV_GZIP,‏ JSON,‏ JSON_GZIP,‏ AVRO,‏ AVRO_DEFLATE,‏ AVRO_SNAPPY,‏ PARQUET,‏ PARQUET_SNAPPY ו-PARQUET_GZIP.
   • ‫AVRO_TYPE: ערך בוליאני. אם הערך הוא false, הסוגים של BigQuery מיוצאים כמחרוזות. אם הערך הוא true, הסוגים מיוצאים כסוג לוגי Avro התואם. חובה למלא את השדה הזה כשgcs_snapshot_format הוא פורמט מסוג Avro.
   • ‫CSV_DELIMITER: התו שמגדיר את ההפרדה בין הערכים בקובצי ה-CSV המיוצאים. הערך יכול להיות כל תו של בית אחד בתקן ISO-8859-1. אפשר להשתמש ב-\t או ב-tab כדי לציין תווי הפרדה של טאבים. חובה למלא את השדה הזה כשgcs_snapshot_format הוא פורמט CSV כלשהו.
   • ‫CSV_EXPORT_HEADER: ערך בוליאני. אם הערך הוא true, כותרות העמודות מיוצאות לקובצי ה-CSV. חובה למלא את השדה הזה כשgcs_snapshot_format הוא פורמט CSV כלשהו.

   פרטים ומיפוי סוגי Avro מופיעים בטבלה הבאה:

   סוג BigQuery	סוג לוגי של Avro
   TIMESTAMP	‫timestamp-micros (annotates Avro LONG)
   DATE	‫date (annotates Avro INT)
   TIME	‫timestamp-micro (annotates Avro LONG)
   DATETIME	STRING (סוג לוגי עם שם מותאם אישית datetime)

4. הוספת משתני ביטול לתיקיות, לפרויקטים, למערכי נתונים ולטבלאות ספציפיים:

     },
     "folder_overrides" : {
      "FOLDER_NUMBER" : {
      },
     },
   
     "project_overrides" : {
      "PROJECT_NAME" : {
      }
     },
   
     "dataset_overrides" : {
      "PROJECT_NAME.DATASET_NAME" : {
      }
     },
   
     "table_overrides" : {
      "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
      }
     }
   }
   

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

   • ‫FOLDER_NUMBER: מציינים את התיקייה שעבורה רוצים להגדיר שדות לביטול.
   • ‫PROJECT_NAME: מציינים את הפרויקט כשמגדירים שדות להחלפה עבור פרויקט, מערך נתונים או טבלה מסוימים.
   • ‫DATASET_NAME: מציינים את מערך הנתונים כשמגדירים שדות להחלפה עבור מערך נתונים או טבלה מסוימים.
   • ‫TABLE_NAME: מציינים את הטבלה שעבורה רוצים להגדיר שדות לביטול.

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

   אם לא רוצים להגדיר ביטולים לרמה מסוימת, מגדירים את המשתנה הזה כמפה ריקה (לדוגמה, project_overrides : {}).

   בדוגמה הבאה, שדות ההחלפה מוגדרים לטבלה ספציפית שמשתמשת בשיטת הצילום של BigQuery:

     },
     "project_overrides" : {},
   
     "table_overrides" : {
      "example_project1.dataset1.table1" : {
       "backup_cron" : "0 0 */5 * * *", # every 5 hours each day
       "backup_method" : "BigQuery Snapshot",
       "backup_time_travel_offset_days" : "7",
       "backup_storage_project" : "project name",
       "backup_operation_project" : "project name",
       # bq settings
       "bq_snapshot_expiration_days" : "14",
       "bq_snapshot_storage_dataset" : "backups2"
       },
      }
   }
   

דוגמה מלאה למדיניות ברירת מחדל מופיעה בקובץ example-variables.

הגדרת פרויקטים נוספים של פעולות גיבוי

• אם רוצים לציין פרויקטים נוספים לגיבוי, כמו אלה שמוגדרים בתצורות חיצוניות (מדיניות גיבוי ברמת הטבלה) או בפרויקטים של מקור הטבלה, צריך להגדיר את המשתנה הבא:

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  מחליפים את ADDITIONAL_BACKUPS ברשימה של שמות פרויקטים מופרדים בפסיקים (לדוגמה, "project1", "project2"). אם משתמשים רק במדיניות ברירת המחדל לגיבוי ללא מדיניות חיצונית ברמת הטבלה, אפשר להגדיר את הערך כרשימה ריקה.

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

הגדרת ההרשאות לחשבון השירות ב-Terraform

בשלבים הקודמים הגדרתם את פרויקטי הגיבוי שבהם יפעלו פעולות הגיבוי. ‫Terraform צריך לפרוס משאבים בפרויקטים של הגיבוי.

לחשבון השירות שבו משתמש Terraform צריכות להיות ההרשאות הנדרשות לפרויקטים הספציפיים של הגיבוי.

• ב-Cloud Shell, נותנים לחשבון השירות הרשאות לכל הפרויקטים שבהם מופעלות פעולות הגיבוי:

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

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

  • ‫BACKUP_OPERATIONS_PROJECT: כל הפרויקטים שמוגדרים בשדות backup_operation_project בכללי מדיניות ברירת המחדל ובכללי המדיניות ברמת הטבלה.
  • ‫DATA_PROJECTS: אם לא מוגדר שדה backup_operation_project במדיניות ברירת מחדל או במדיניות ברמת הטבלה, צריך לכלול את הפרויקטים של טבלאות המקור האלה.
  • ‫ADDITIONAL_BACKUPS: כל הפרויקטים שמוגדרים במשתנה Terraform‏ additional_backup_operation_projects.

הפעלת סקריפטים לפריסה

1. ב-Cloud Shell, מריצים את סקריפט הפריסה של Terraform:

   cd terraform
   
   terraform init \
       -backend-config="bucket=${BUCKET_NAME}" \
       -backend-config="prefix=terraform-state" \
       -backend-config="impersonate_service_account=$TF_SA@$PROJECT_ID.iam.gserviceaccount.com"
   
   terraform plan -var-file=$VARS
   
   terraform apply -var-file=$VARS
   

2. מוסיפים את מדיניות אורך החיים (TTL) של Firestore:

   
   gcloud firestore fields ttls update expires_at \
       --collection-group=project_folder_cache \
       --enable-ttl \
       --async \
       --project=$PROJECT_ID
   

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

הגדרת גישה למקורות וליעדים

1. ב-Cloud Shell, מגדירים את המשתנים הבאים עבור חשבונות השירות שבהם נעשה שימוש בפתרון:

   export SA_DISPATCHER_EMAIL=dispatcher@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_CONFIGURATOR_EMAIL=configurator@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_SNAPSHOTER_BQ_EMAIL=snapshoter-bq@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_SNAPSHOTER_GCS_EMAIL=snapshoter-gcs@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_TAGGER_EMAIL=tagger@${PROJECT_ID}.iam.gserviceaccount.com
   

   אם שיניתם את שמות ברירת המחדל ב-Terraform, צריך לעדכן את כתובות האימייל של חשבון השירות.

2. אם הגדרתם את השדה folders_include_list ואתם רוצים להגדיר את היקף הסריקה של BigQuery כך שיכלול תיקיות מסוימות, צריך להעניק את ההרשאות הנדרשות ברמת התיקייה:

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

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

   ./scripts/prepare_data_projects.sh DATA_PROJECTS
   ./scripts/prepare_backup_storage_projects.sh BACKUP_STORAGE_PROJECT
   ./scripts/prepare_backup_operation_projects.sh BACKUP_OPERATIONS_PROJECT
   

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

   • ‫DATA_PROJECTS: פרויקטים של נתונים (או פרויקטים של מקורות) שמכילים את טבלאות המקור שרוצים לגבות (לדוגמה, project1 project2). צריך לכלול את הפרויקטים הבאים:

     • פרויקטים שמצוינים ברשימות ההכללה במשתנה schedulers של Terraform.
     • אם רוצים לגבות טבלאות בפרויקט המארח, צריך לכלול את הפרויקט המארח.

   • ‫BACKUP_STORAGE_PROJECT: פרויקטים של אחסון הגיבוי (או פרויקטים של יעד) שבהם הפתרון מאחסן את הגיבויים (לדוגמה, project1 project2). צריך לכלול את הפרויקטים שמצוינים בשדות הבאים:

     • השדות backup_storage_project בכל כללי מדיניות החזרה לאחור.
     • השדות backup_storage_project בכללי המדיניות ברמת הטבלה.

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

   • ‫BACKUP_OPERATIONS_PROJECT: הפרויקטים של פעולות הנתונים שבהם הפתרון מריץ את פעולות הגיבוי (לדוגמה, project1 project2). צריך לכלול את הפרויקטים שמצוינים בשדות הבאים:

     • השדות backup_operation_project בכל כללי מדיניות החזרה לאחור.
     • כל רשימות ההכללה בהיקף הסריקה של BigQuery (אם לא מגדירים את השדה backup_operation_project).
     • השדות backup_operation_project בכל המדיניות ברמת הטבלה.

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

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

   TAXONOMY="projects/TAXONOMY_PROJECT/locations/TAXONOMY_LOCATION/taxonomies/TAXONOMY_ID"
   
   gcloud data-catalog taxonomies add-iam-policy-binding \
   $TAXONOMY \
   --member="serviceAccount:${SA_SNAPSHOTER_BQ_EMAIL}" \
   --role='roles/datacatalog.categoryFineGrainedReader'
   
   gcloud data-catalog taxonomies add-iam-policy-binding \
   $TAXONOMY \
   --member="serviceAccount:${SA_SNAPSHOTER_GCS_EMAIL}" \
   --role='roles/datacatalog.categoryFineGrainedReader'
   

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

   • ‫TAXONOMY_PROJECT: מזהה הפרויקט בטקסונומיה של תג המדיניות
   • ‫TAXONOMY_LOCATION: המיקום שצוין בטקסונומיה של תג המדיניות
   • ‫TAXONOMY_ID: מזהה הטקסונומיה של מדיניות הטקסונומיה של תגי המדיניות

5. חוזרים על השלב הקודם לכל טקסונומיה של תגי מדיניות.

הרצת הפתרון

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

הגדרת מדיניות גיבוי ברמת הטבלה

• ב-Cloud Shell, יוצרים מדיניות ברמת הטבלה עם השדות הנדרשים, ואז מאחסנים את המדיניות בקטגוריה של Cloud Storage למדיניות:

  # Use the default backup policies bucket unless overwritten in the .tfvars
  export POLICIES_BUCKET=${PROJECT_ID}-bq-backup-manager-policies
  
  # set target table info
  export TABLE_PROJECT='TABLE_PROJECT'
  export TABLE_DATASET='TABLE_DATASET'
  export TABLE='TABLE_NAME'
  
  # Config Source must be 'MANUAL' when assigned this way
  export BACKUP_POLICY="{
  'config_source' : 'MANUAL',
  'backup_cron' : 'BACKUP_CRON',
  'backup_method' : 'BACKUP_METHOD',
  'backup_time_travel_offset_days' : 'OFFSET_DAYS',
  'backup_storage_project' : 'BACKUP_STORAGE_PROJECT',
  'backup_operation_project' : 'BACKUP_OPERATION_PROJECT',
  'gcs_snapshot_storage_location' : 'STORAGE_BUCKET',
  'gcs_snapshot_format' : 'FILE_FORMAT',
  'gcs_avro_use_logical_types' : 'AVRO_TYPE',
  'bq_snapshot_storage_dataset' : 'DATASET_NAME',
  'bq_snapshot_expiration_days' : 'SNAPSHOT_EXPIRATION'
  }"
  
  # File name MUST BE backup_policy.json
  echo $BACKUP_POLICY >> backup_policy.json
  
  gcloud storage cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json
  

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

  • ‫TABLE_PROJECT: הפרויקט שבו נמצאת הטבלה
  • ‫TABLE_DATASET: מערך הנתונים של הטבלה
  • ‫TABLE_NAME: שם הטבלה

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

המשימות של Cloud Scheduler שהגדרתם קודם יפעלו אוטומטית בהתאם לביטוי ה-cron שלהן.

אפשר גם להפעיל את העבודות באופן ידני במסוף Google Cloud . מידע נוסף זמין במאמר בנושא הפעלת עבודה.

מעקב ודיווח

אחרי שבוחרים את פרויקט המארח (PROJECT_ID), אפשר להריץ את השאילתות הבאות ב-BigQuery Studio כדי לקבל דוחות ומידע.

• אפשר לקבל נתונים סטטיסטיים על ההתקדמות של כל הפעלה (כולל הפעלות בתהליך):

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• קבלת כל השגיאות הקריטיות (שלא ניתן לנסות שוב לפתור) של ריצה יחידה:

  SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
  WHERE run_id = 'RUN_ID'
  

  מחליפים את RUN_ID במזהה ההרצה.

• קבלת כל ההרצות בטבלה ופרטי הביצוע שלהן:

  SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
  WHERE tablespec = 'project.dataset.table'
  

  אפשר גם לציין גרסת grouped:

  SELECT * FROM `bq_backup_manager.v_audit_log_by_table_grouped`, UNNEST(runs) r
  WHERE r.run_has_retryable_error = FALSE
  

• לצורך ניפוי באגים, אפשר לקבל מידע מפורט על בקשות ותגובות לכל קריאה לשירות:

  SELECT
  jsonPayload.unified_target_table AS tablespec,
  jsonPayload.unified_run_id AS run_id,
  jsonPayload.unified_tracking_id AS tracking_id,
  CAST(jsonPayload.unified_is_successful AS BOOL) AS configurator_is_successful,
  jsonPayload.unified_error AS configurator_error,
  CAST(jsonPayload.unified_is_retryable_error AS BOOL) AS configurator_is_retryable_error,
  CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isForceRun') AS BOOL) AS is_force_run,
  CAST(JSON_VALUE(jsonPayload.unified_output_json, '$.isBackupTime') AS BOOL) AS is_backup_time,
  JSON_VALUE(jsonPayload.unified_output_json, '$.backupPolicy.method') AS backup_method,
  CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isDryRun') AS BOOL) AS is_dry_run,
  jsonPayload.unified_input_json AS request_json,
  jsonPayload.unified_output_json AS response_json
  FROM `bq_backup_manager.run_googleapis_com_stdout`
  WHERE jsonPayload.global_app_log = 'UNIFIED_LOG'
  -- 1= dispatcher, 2= configurator, 3=bq snapshoter, -3=gcs snapshoter and 4=tagger
  AND jsonPayload.unified_component = "2"
  

• קבלת מדיניות הגיבוי שנוספה או הוקצתה באופן ידני על ידי המערכת על סמך חלופות:

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

מגבלות

מידע נוסף על מגבלות ומכסות לכל פרויקט שצוין בשדות backup_operation_project זמין במאמר מגבלות.

הסרת המשאבים

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

מחיקת הפרויקטים

זהירות: כשמוחקים פרויקט:

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת המשאבים החדשים

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

• ב-Cloud Shell, מוחקים את המשאבים של Terraform:

  terraform destroy -var-file="${VARS}"
  

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

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

• מידע נוסף על BigQuery:
  • תמונות מצב של טבלאות ב-BigQuery
  • ייצוא טבלאות BigQuery ל-Cloud Storage
• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.

שותפים ביצירת התוכן

המחבר: Karim Wadie | מהנדס ענן אסטרטגי

תורמי תוכן אחרים:

• Chris DeForeest | Site Reliability Engineer
• אייל בן עברי | Cloud Solutions Architect
• ג'ייסון דבנפורט | אחראי קשרי מפתחים
• Jaliya Ekanayake | Engineering Manager
• Muhammad Zain | Strategic Cloud Engineer