Diese Seite wurde von der Cloud Translation API übersetzt.

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:

Architektur für die automatisierte Sicherungslösung.

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:

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

Neuen Google Cloud Nutzern 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.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
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.
Installieren Sie Maven:
1. Maven herunterladen
2. Fügen Sie in Cloud Shell Maven zu PATH hinzu:
```
export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
```

Klonen Sie in Cloud Shell das GitHub-Repository:

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

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.

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

Terraform-Zustands-Bucket vorbereiten:

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

Terraform-Dienstkonto vorbereiten:

./scripts/prepare_terraform_service_account.sh

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 der Anleitung, 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.

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

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 Bilder in den Cloud Run-Diensten zu verwenden, die Terraform später erstellt.

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.

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:
- Schließen Sie alle Dataset-Namen aus, 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.

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 (um die Methode „Exportieren nach Cloud Storage“ zu verwenden) 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.
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.

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 der Wert auf 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`)

Ü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

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

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

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.

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
```
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.
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
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 Konsole 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 Ausführungen 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, können Sie entweder die Projekte löschen, die die Ressourcen enthalten, oder die Projekte beibehalten und die einzelnen Ressourcen löschen.

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, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt 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

Skalierbare BigQuery-Sicherungsautomatisierung bereitstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Architektur

Ziele

Kosten

Hinweise

Stellen Sie die Infrastruktur bereit:

gcloud CLI-Konfiguration aktivieren

Cloud Run-Dienst-Images erstellen

Terraform-Variablen konfigurieren

Fallback-Richtlinien definieren

Zusätzliche Projekte für Sicherungsvorgänge konfigurieren

Berechtigungen für das Terraform-Dienstkonto konfigurieren

Bereitstellungsskripts ausführen

Zugriff auf Quellen und Ziele einrichten

Lösung ausführen

Sicherungsrichtlinien auf Tabellenebene festlegen

Sicherungsvorgänge auslösen

Überwachen und Berichte erstellen

Beschränkungen

Bereinigen

Projekte löschen

Die Neuen Ressourcen löschen

Nächste Schritte

Beitragende

Skalierbare BigQuery-Sicherungsautomatisierung bereitstellen