Skalierbare BigQuery-Sicherungsautomatisierung bereitstellen

Last reviewed 2024-09-17 UTC

In diesem Dokument wird beschrieben, wie Sie die skalierbare BigQuery-Sicherungsautomatisierung bereitstellen.

Dieses Dokument richtet sich an Cloud-Architekten, Entwickler und Data Governance-Beauftragte, die Datenrichtlinien in ihren Organisationen definieren und automatisieren möchten. Erfahrung mit Terraform ist hilfreich.

Architektur

Das folgende Diagramm zeigt die Architektur für automatisierte Back-ups:

Cloud Scheduler löst den Lauf aus. Der Dispatcher-Dienst listet mithilfe der BigQuery API die infrage kommenden Tabellen auf. Über eine Pub/Sub-Nachricht sendet der Dispatcher-Dienst für jede Tabelle eine Anfrage an den Konfigurator-Dienst. Der Konfigurationsdienst bestimmt die Sicherungsrichtlinien für die Tabellen und sendet dann für jede Tabelle eine Anfrage an den entsprechenden Cloud Run-Dienst. Der Cloud Run-Dienst sendet dann eine Anfrage an die BigQuery API und führt die Sicherungsvorgänge aus. Pub/Sub löst den Tagger-Dienst aus, der die Ergebnisse protokolliert und den Sicherungsstatus in der Cloud Storage-Metadatenebene aktualisiert.

Details zur Architektur finden Sie unter Skalierbare BigQuery-Sicherungsautomatisierung.

Ziele

• Cloud Run-Dienste erstellen
• Konfigurieren Sie Terraform-Variablen.
• Führen Sie die Terraform- und manuellen Bereitstellungsskripts aus.
• Führen Sie die Lösung aus.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

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

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Neuen Nutzern von Google Cloud steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

Wenn Sie die Lösung noch einmal bereitstellen, können Sie diesen Abschnitt überspringen (z. B. nach neuen Commits).

In diesem Abschnitt erstellen Sie einmalige Ressourcen.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Wenn Sie ein neues Google Cloud -Projekt als Hostprojekt für das Deployment erstellen möchten, verwenden Sie den Befehl gcloud projects create:

      gcloud projects create PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch die ID des Projekts, das Sie erstellen möchten.

3. Installieren Sie Maven:

   1. Maven herunterladen.

   2. Fügen Sie in Cloud Shell Maven zu PATH hinzu:

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
      

4. Klonen Sie in Cloud Shell das GitHub-Repository:

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

5. Legen Sie die folgenden Umgebungsvariablen fest und exportieren Sie sie:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: die ID des Google Cloud Hostprojekts Google Cloud , in dem Sie die Lösung bereitstellen möchten.
   • COMPUTE_REGION: Die Google Cloud Region, in der Sie Rechenressourcen wie Cloud Run und Identity and Access Management (IAM) bereitstellen möchten.
   • DATA_REGION: Die Google Cloud Region, in der Sie Datenressourcen (z. B. Buckets und Datasets) bereitstellen möchten.
   • ACCOUNT_EMAIL: die E-Mail-Adresse des Nutzerkontos.

6. APIs aktivieren:

   ./scripts/enable_gcp_apis.sh
   

   Das Skript aktiviert die folgenden APIs:

   • 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-Zustands-Bucket vorbereiten:

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

8. Terraform-Dienstkonto vorbereiten:

   ./scripts/prepare_terraform_service_account.sh
   

9. Wenn Sie die von dieser Lösung verwendeten Bilder veröffentlichen möchten, bereiten Sie ein Docker-Repository vor:

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

Stellen Sie die Infrastruktur bereit:

Sie müssen die Schritte unter Vorbereitung mindestens einmal ausgeführt haben.

In diesem Abschnitt folgen Sie den Schritten, um die aktuelle Codebasis in der Google Cloud -Umgebung bereitzustellen oder noch einmal bereitzustellen.

gcloud CLI-Konfiguration aktivieren

• Aktivieren und authentifizieren Sie die gcloud CLI-Konfiguration in Cloud Shell:

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

Cloud Run-Dienst-Images erstellen

• Erstellen und stellen Sie in Cloud Shell Docker-Images bereit, die vom Cloud Run-Dienst verwendet werden sollen:

  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-Variablen konfigurieren

Bei dieser Bereitstellung werden Terraform für Konfigurationen und ein Bereitstellungsskript verwendet.

1. Erstellen Sie in Cloud Shell eine neue Terraform-TFVARS-Datei, in der Sie die Variablen in diesem Abschnitt überschreiben können:

   export VARS=FILENAME
   .tfvars
   

   Ersetzen Sie FILENAME durch den Namen der von Ihnen erstellten Variablendatei, z. B. my-variables. Sie können die Datei example-variables als Referenz verwenden.

2. Konfigurieren Sie in der TFVARS-Datei die Projektvariablen:

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

   Sie können die in der Datei variables.tf definierten Standardwerte verwenden oder die Werte ändern.

3. Konfigurieren Sie das Terraform-Dienstkonto, das Sie zuvor unter Vorbereitung erstellt und vorbereitet haben:

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

   Verwenden Sie die vollständige E-Mail-Adresse des Kontos, das Sie erstellt haben.

4. Konfigurieren Sie die Cloud Run-Dienste so, dass die Container-Images verwendet werden, die Sie zuvor erstellt und bereitgestellt haben:

   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"
   

   Dieses Skript weist Terraform an, diese veröffentlichten Images in den Cloud Run-Diensten zu verwenden, die später von Terraform erstellt werden.

   Terraform verknüpft einen Cloud Run-Dienst nur mit einem vorhandenen Image. Die Images werden nicht aus dem Code erstellt, da dies in einem vorherigen Schritt erfolgt ist.

5. Definieren Sie in der Variablen schedulers mindestens einen Scheduler. Der Scheduler listet Tabellen regelmäßig auf und prüft sie anhand ihrer Cron-Zeitpläne für Sicherungen auf Tabellenebene auf erforderliche Sicherungen.

   {
   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]
       }
   }
   

   Ersetzen Sie Folgendes:

   • SCHEDULER_NAME: Der Anzeigename des Cloud Scheduler.
   • SCHEDULER_CRON: die Häufigkeit, mit der der Scheduler prüft, ob für die infrage kommenden Tabellen eine Sicherung ansteht. Die Prüfung erfolgt anhand der individuellen Sicherungszeitpläne der Tabellen. Dies kann ein beliebiger Unix-Cron-kompatibler String sein. 0 * * * * ist beispielsweise eine stündliche Häufigkeit.
   • FORCE_RUN: Ein boolescher Wert. Legen Sie den Wert auf false fest, wenn der Scheduler die Cron-Zeitpläne der Tabellen verwenden soll. Wenn der Wert auf true festgelegt ist, werden alle infrage kommenden Tabellen gesichert, unabhängig von ihrer Cron-Einstellung.
   • DRY_RUN: Ein boolescher Wert. Wenn true festgelegt ist, werden keine tatsächlichen Sicherungsvorgänge ausgeführt. Es werden nur Log-Nachrichten generiert. Verwenden Sie true, wenn Sie die Lösung testen und debuggen möchten, ohne dass Sicherungskosten anfallen.
   • FOLDERS_INCLUDED: Eine Liste mit numerischen IDs für Ordner, die BigQuery-Daten enthalten (z. B. 1234, 456). Wenn diese Option festgelegt ist, werden die Tabellen in den angegebenen Ordnern gesichert und die Feldeinstellungen projects_include_list, datasets_include_list und tables_include_list werden ignoriert.
   • PROJECTS_INCLUDED: eine Liste von Projektnamen (z. B. "project1", "project2"). Wenn diese Option festgelegt ist, werden die Tabellen in den angegebenen Projekten gesichert und die Einstellungen für die Felder datasets_include_list und tables_include_list werden ignoriert. Diese Einstellung wird ignoriert, wenn Sie das Feld folders_include_list festlegen.
   • PROJECTS_EXCLUDED: Eine Liste mit Projektnamen oder ein regulärer Ausdruck (z. B. "project1", "regex:^test_"). Wenn diese Option festgelegt ist, werden keine Sicherungen der Tabellen in den angegebenen Projekten erstellt. Sie können diese Einstellung in Kombination mit dem Feld folders_include_list verwenden.
   • DATASETS_INCLUDED: Eine Liste von Datasets, z. B. "project1.dataset1", "project1.dataset2". Wenn diese Option festgelegt ist, werden die Tabellen in den angegebenen Datasets gesichert und die Einstellung des Felds tables_include_list wird ignoriert. Diese Einstellung wird ignoriert, wenn Sie die Felder folders_include_list oder projects_include_list festlegen.
   • DATASETS_EXCLUDED: Eine Liste von Datasets oder ein regulärer Ausdruck (z. B. "project1.dataset1", "regex:.*\\_landing$"). Wenn diese Option festgelegt ist, werden keine Back-ups der Tabellen in den angegebenen Datasets erstellt. Sie können diese Einstellung in Kombination mit den Feldern folders_include_list oder projects_include_list verwenden.
   • TABLES_INCLUDED: Eine Liste von Tabellen, z. B. "project1.dataset1.table 1", "project1.dataset2.table2". Wenn diese Option festgelegt ist, werden die angegebenen Tabellen gesichert. Diese Einstellung wird ignoriert, wenn Sie die Felder folders_include_list, projects_include_list oder datasets_include_list festlegen.
   • TABLES_EXCLUDED: Eine Liste von Tabellen oder ein regulärer Ausdruck (z. B. "project1.dataset1.table 1", "regex:.*\_test"). Wenn diese Option festgelegt ist, werden keine Back-ups der angegebenen Tabellen erstellt. Sie können diese Einstellung in Kombination mit den Feldern folders_include_list, projects_include_list oder datasets_include_list verwenden.

   Für alle Ausschlusslisten sind reguläre Ausdrücke in der Form regex:REGULAR_EXPRESSION zulässig.

   Wenn der voll qualifizierte Name des Eintrags (z. B. "project.dataset.table") mit einem der angegebenen regulären Ausdrücke übereinstimmt, wird er aus dem Sicherungsbereich ausgeschlossen.

   Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:

   • Alle Dataset-Namen ausschließen, die mit _landing enden: datasets_exclude_list = ["regex:.*\\_landing$"]
   • Alle Tabellen ausschließen, die mit _test, _tst, _bkp oder _copy enden: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

Fallback-Richtlinien definieren

Bei jedem Lauf muss die Lösung die Sicherungsrichtlinie für jede Tabelle im Geltungsbereich ermitteln. Weitere Informationen zu den Arten von Richtlinien finden Sie unter Sicherungsrichtlinien. In diesem Abschnitt erfahren Sie, wie Sie eine Fallback-Richtlinie definieren.

Eine Fallback-Richtlinie wird mit einer default_policy-Variablen und einer Reihe von Ausnahmen oder Überschreibungen auf verschiedenen Ebenen (Ordner, Projekt, Dataset und Tabelle) definiert. Dieser Ansatz bietet eine hohe Flexibilität, ohne dass für jede Tabelle ein Eintrag erforderlich ist.

Je nach verwendeter Sicherungsmethode gibt es zusätzliche Gruppen von Richtlinienfeldern: BigQuery-Snapshots, Exporte nach Cloud Storage oder beides.

1. Legen Sie in der TFVARS-Datei für die Variable default_policy die folgenden allgemeinen Felder für die Standardrichtlinie fest:

   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",
   
   

   Ersetzen Sie Folgendes:

   • BACKUP_CRON: Ein Cron-Ausdruck, mit dem die Häufigkeit festgelegt wird, mit der eine Tabelle gesichert wird. Wenn Sie beispielsweise alle 6 Stunden Sicherungen erstellen möchten, geben Sie 0 0 */6 * * * an. Dies muss ein mit dem Spring-Framework kompatibler Cron-Ausdruck sein.
   • BACKUP_METHOD: Die Methode, die Sie als BigQuery Snapshot, GCS Snapshot (für die Methode „Exportieren nach Cloud Storage“) oder Both angeben. Sie müssen die erforderlichen Felder für jede ausgewählte Sicherungsmethode angeben, wie unten beschrieben.
   • OFFSET_DAYS: Die Anzahl der Tage in der Vergangenheit, die den Zeitpunkt bestimmt, ab dem die Tabellen gesichert werden sollen. Die Werte können eine Zahl zwischen 0 und 7 sein.
   • BACKUP_STORAGE_PROJECT: die ID des Projekts, in dem alle Snapshot- und Exportvorgänge gespeichert sind. Dies ist dasselbe Projekt, in dem sich bq_snapshot_storage_dataset und gcs_snapshot_storage_location befinden. Bei kleinen Bereitstellungen kann das Hostprojekt verwendet werden, bei großen Bereitstellungen sollte jedoch ein separates Projekt verwendet werden.
   • BACKUP_OPERATIONS_PROJECT: eine optionale Einstellung, mit der Sie die ID des Projekts angeben, in dem alle Snapshot- und Exportvorgänge ausgeführt werden. Für dieses Projekt gelten die Kontingente und Limits für Snapshot- und Exportjobs. Dieser kann mit backup_storage_project identisch sein. Wenn nicht festgelegt, wird das Projekt der Quelltabelle verwendet.

2. Wenn Sie BigQuery Snapshot oder Both als backup_method angegeben haben, fügen Sie die folgenden Felder nach den gemeinsamen Feldern in der Variablen default_policy hinzu:

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

   Ersetzen Sie Folgendes:

   • SNAPSHOT_EXPIRATION: die Anzahl der Tage, für die jeder Snapshot aufbewahrt werden soll (z. B. 15).
   • DATASET_NAME: der Name des Datasets, in dem Snapshots gespeichert werden sollen (z. B. backups). Das Dataset muss bereits im Projekt vorhanden sein, das für backup_storage_project angegeben ist.

3. Wenn Sie GCS Snapshot (für die Methode „Export nach Cloud Storage“) oder Both als backup_method angegeben haben, fügen Sie der Variablen default_policy die folgenden Felder hinzu:

     "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
   

   Ersetzen Sie Folgendes:

   • STORAGE_BUCKET: Der Cloud Storage-Bucket, in dem die exportierten Daten gespeichert werden sollen, im Format gs://bucket/path/. Beispiel: gs://bucket1/backups/.
   • FILE_FORMAT: Das Dateiformat und die Komprimierung, die zum Exportieren einer BigQuery-Tabelle nach Cloud Storage verwendet werden. Verfügbare Werte sind CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY und PARQUET_GZIP.
   • AVRO_TYPE: Ein boolescher Wert. Wenn false festgelegt ist, werden die BigQuery-Typen als Strings exportiert. Wenn diese Option auf true gesetzt ist, werden die Typen als die entsprechenden logischen Avro-Typen exportiert. Dieses Feld ist erforderlich, wenn gcs_snapshot_format ein beliebiges Avro-Typformat ist.
   • CSV_DELIMITER: Das Trennzeichen, das für die exportierten CSV-Dateien verwendet wird. Der Wert kann ein beliebiges ISO-8859-1-Einzelbytezeichen sein. Sie können \t oder tab verwenden, um Tabulatortrennzeichen anzugeben. Dieses Feld ist erforderlich, wenn gcs_snapshot_format ein CSV-Format ist.
   • CSV_EXPORT_HEADER: Ein boolescher Wert. Wenn true festgelegt ist, werden die Spaltenüberschriften in die CSV-Dateien exportiert. Dieses Feld ist erforderlich, wenn gcs_snapshot_format ein CSV-Format ist.

   Weitere Informationen und die Zuordnung von Avro-Typen finden Sie in der folgenden Tabelle:

   BigQuery-Typ	Logischer Avro-Typ
   TIMESTAMP	timestamp-micros (annotates Avro LONG)
   DATE	date (annotates Avro INT)
   TIME	timestamp-micro (annotates Avro LONG)
   DATETIME	STRING (benutzerdefinierter logischer Typ mit dem Namen datetime)

4. Überschreibungsvariablen für bestimmte Ordner, Projekte, Datasets und Tabellen hinzufügen:

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

   Ersetzen Sie Folgendes:

   • FOLDER_NUMBER: Geben Sie den Ordner an, für den Sie Überschreibungsfelder festlegen möchten.
   • PROJECT_NAME: Geben Sie das Projekt an, wenn Sie Überschreibungsfelder für ein bestimmtes Projekt, Dataset oder eine bestimmte Tabelle festlegen.
   • DATASET_NAME: Geben Sie das Dataset an, wenn Sie Überschreibungsfelder für ein bestimmtes Dataset oder eine bestimmte Tabelle festlegen.
   • TABLE_NAME: Geben Sie die Tabelle an, für die Sie Überschreibungsfelder festlegen möchten.

   Fügen Sie für jeden Überschreibungs-Eintrag, z. B. ein bestimmtes Projekt in der Variablen project_overrides, die gemeinsamen Felder und die erforderlichen Felder für die Sicherungsmethode hinzu, die Sie zuvor in default_policy angegeben haben.

   Wenn Sie keine Überschreibungen für eine bestimmte Ebene festlegen möchten, setzen Sie die entsprechende Variable auf eine leere Map (z. B. project_overrides : {}).

   Im folgenden Beispiel werden Überschreibungsfelder für eine bestimmte Tabelle festgelegt, für die die BigQuery-Snapshot-Methode verwendet wird:

     },
     "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"
       },
      }
   }
   

Ein vollständiges Beispiel für eine Fallback-Richtlinie finden Sie in der Datei example-variables.

Zusätzliche Projekte für Sicherungsvorgänge konfigurieren

• Wenn Sie zusätzliche Sicherungsprojekte angeben möchten, z. B. solche, die in externen Konfigurationen (Sicherungsrichtlinie auf Tabellenebene) oder den Tabellenquellenprojekten definiert sind, konfigurieren Sie die folgende Variable:

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  Ersetzen Sie ADDITIONAL_BACKUPS durch eine durch Kommas getrennte Liste mit Projektnamen (z. B. "project1", "project2"). Wenn Sie nur die Fallback-Sicherungsrichtlinie ohne externe Richtlinien auf Tabellenebene verwenden, können Sie den Wert auf eine leere Liste festlegen.

  Wenn Sie dieses Feld nicht hinzufügen, werden alle Projekte, die im optionalen Feld backup_operation_project angegeben sind, automatisch als Sicherungsprojekte aufgenommen.

Berechtigungen für das Terraform-Dienstkonto konfigurieren

In den vorherigen Schritten haben Sie die Sicherungsprojekte konfiguriert, in denen die Sicherungsvorgänge ausgeführt werden. Terraform muss Ressourcen in diesen Sicherungsprojekten bereitstellen.

Das von Terraform verwendete Dienstkonto muss die erforderlichen Berechtigungen für diese angegebenen Sicherungsprojekte haben.

• Gewähren Sie dem Dienstkonto in Cloud Shell Berechtigungen für alle Projekte, in denen Sicherungsvorgänge ausgeführt werden:

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

  Ersetzen Sie Folgendes:

  • BACKUP_OPERATIONS_PROJECT: Alle Projekte, die in den Feldern backup_operation_project in einer der Fallback-Richtlinien und Richtlinien auf Tabellenebene definiert sind.
  • DATA_PROJECTS: Wenn in einer Fallback- oder Richtlinie auf Tabellenebene kein backup_operation_project-Feld definiert ist, fügen Sie die Projekte für diese Quelltabellen ein.
  • ADDITIONAL_BACKUPS: Alle Projekte, die in der Terraform-Variablen additional_backup_operation_projects definiert sind.

Bereitstellungsskripts ausführen

1. Führen Sie in Cloud Shell das Terraform-Bereitstellungsskript aus:

   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. Fügen Sie die Richtlinien zur Gültigkeitsdauer (TTL) für Firestore hinzu:

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

   In einigen Situationen wird Datastore als Cache verwendet. Um Kosten zu sparen und die Suchleistung zu verbessern, können mit der TTL-Richtlinie abgelaufene Einträge in Firestore automatisch gelöscht werden.

Zugriff auf Quellen und Ziele einrichten

1. Legen Sie in Cloud Shell die folgenden Variablen für die von der Lösung verwendeten Dienstkonten fest:

   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
   

   Wenn Sie die Standardnamen in Terraform geändert haben, aktualisieren Sie die E-Mail-Adressen des Dienstkontos.

2. Wenn Sie das Feld folders_include_list festgelegt haben und den Umfang des BigQuery-Scans auf bestimmte Ordner beschränken möchten, gewähren Sie die erforderlichen Berechtigungen auf Ordnerebene:

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

3. Damit die Anwendung die erforderlichen Aufgaben in verschiedenen Projekten ausführen kann, müssen Sie die erforderlichen Berechtigungen für jedes dieser Projekte gewähren:

   ./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
   

   Ersetzen Sie Folgendes:

   • DATA_PROJECTS: die Datenprojekte (oder Quellprojekte), die die Quelltabellen enthalten, die Sie sichern möchten, z. B. project1 project2. Fügen Sie die folgenden Projekte ein:

     • Projekte, die in den Einschlusslisten in der Terraform-Variablen schedulers angegeben sind.
     • Wenn Sie Tabellen im Hostprojekt sichern möchten, müssen Sie das Hostprojekt einbeziehen.

   • BACKUP_STORAGE_PROJECT: die Projekte für die Sicherungsspeicherung (oder Zielprojekte), in denen die Sicherungen gespeichert werden, z. B. project1 project2. Sie müssen die Projekte angeben, die in den folgenden Feldern angegeben sind:

     • Die Felder backup_storage_project in allen Fallback-Richtlinien.
     • Die backup_storage_project-Felder in allen Richtlinien auf Tabellenebene.

     Sicherungsspeicherprojekte einbeziehen, die in mehreren Feldern verwendet werden oder sowohl als Quell- als auch als Zielprojekt dienen

   • BACKUP_OPERATIONS_PROJECT: Die Projekte für Datenvorgänge, in denen die Lösung die Sicherungsvorgänge ausführt (z. B. project1 project2). Sie müssen die Projekte angeben, die in den folgenden Feldern angegeben sind:

     • Die Felder backup_operation_project in allen Fallback-Richtlinien.
     • Alle Einschlusslisten im Rahmen des BigQuery-Scans (wenn Sie das Feld backup_operation_project nicht festlegen).
     • Die backup_operation_project-Felder in allen Richtlinien auf Tabellenebene.

     Schließen Sie Projekte für Sicherungsvorgänge ein, die in mehreren Feldern verwendet werden oder sowohl als Quell- als auch als Zielprojekt dienen.

4. Bei Tabellen, die die Zugriffssteuerung auf Spaltenebene verwenden, müssen Sie alle Richtlinien-Tag-Taxonomien ermitteln, die von Ihren Tabellen verwendet werden (falls vorhanden), und den Dienstkonten der Lösung Zugriff auf die Tabellendaten gewähren:

   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'
   

   Ersetzen Sie Folgendes:

   • TAXONOMY_PROJECT: die Projekt-ID in der Taxonomie für Richtlinientags
   • TAXONOMY_LOCATION: der in der Taxonomie für Richtlinientags angegebene Speicherort
   • TAXONOMY_ID: Die Taxonomie-ID der Taxonomie des Richtlinien-Tags

5. Wiederholen Sie den vorherigen Schritt für jede Richtlinientag-Taxonomie.

Lösung ausführen

Nachdem Sie die Lösung bereitgestellt haben, können Sie sie mithilfe der folgenden Abschnitte ausführen und verwalten.

Sicherungsrichtlinien auf Tabellenebene festlegen

• Erstellen Sie in Cloud Shell eine Richtlinie auf Tabellenebene mit den erforderlichen Feldern und speichern Sie die Richtlinie dann im Cloud Storage-Bucket für Richtlinien:

  # 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
  

  Ersetzen Sie Folgendes:

  • TABLE_PROJECT: das Projekt, in dem sich die Tabelle befindet
  • TABLE_DATASET: das Dataset der Tabelle
  • TABLE_NAME: der Name der Tabelle

Sicherungsvorgänge auslösen

Die Cloud Scheduler-Jobs, die Sie zuvor konfiguriert haben, werden automatisch gemäß ihrem Cron-Ausdruck ausgeführt.

Sie können die Jobs auch manuell in der Google Cloud Console ausführen. Weitere Informationen finden Sie unter Job ausführen.

Überwachen und Berichte erstellen

Wenn Ihr Hostprojekt (PROJECT_ID) ausgewählt ist, können Sie die folgenden Abfragen in BigQuery Studio ausführen, um Berichte und Informationen zu erhalten.

• Fortschrittsstatistiken für jeden Lauf abrufen (einschließlich laufender Läufe):

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• Alle schwerwiegenden (nicht wiederholbaren) Fehler für einen einzelnen Lauf abrufen:

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

  Ersetzen Sie RUN_ID durch die ID des Laufs.

• Alle Läufe in einer Tabelle und ihre Ausführungsinformationen abrufen:

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

  Sie können auch eine grouped-Version angeben:

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

• Zur Fehlerbehebung können Sie detaillierte Informationen zu Anfragen und Antworten für jeden Dienstaufruf abrufen:

  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"
  

• Rufen Sie die Sicherungsrichtlinien ab, die manuell hinzugefügt oder vom System basierend auf Fallbacks zugewiesen wurden:

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

Beschränkungen

Weitere Informationen zu Limits und Kontingenten für jedes Projekt, das in den backup_operation_project-Feldern angegeben ist, finden Sie unter Limits.

Bereinigen

Damit Ihrem Google Cloud -Konto die in dieser Bereitstellung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder die Projekte, die die Ressourcen enthalten, oder behalten Sie die Projekte bei und löschen Sie die einzelnen Ressourcen.

Projekte löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Die Neuen Ressourcen löschen

Als Alternative zum Löschen der Projekte können Sie die Ressourcen löschen, die Sie während dieses Vorgangs erstellt haben.

• Löschen Sie in Cloud Shell die Terraform-Ressourcen:

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

  Mit dem Befehl werden fast alle Ressourcen gelöscht. Prüfen Sie, ob alle Ressourcen, die Sie löschen möchten, entfernt wurden.

Nächste Schritte

• Weitere Informationen zu BigQuery:
  • BigQuery-Tabellensnapshots
  • BigQuery-Tabellenexporte nach Cloud Storage
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.

Beitragende

Autor: Karim Wadie | Strategic Cloud Engineer

Weitere Beitragende:

• Chris DeForeest | Site Reliability Engineer
• Eyal Ben Ivri | Cloud Solutions Architect
• Jason Davenport | Developer Advocate
• Jaliya Ekanayake | Engineering Manager
• Muhammad Zain | Strategic Cloud Engineer