Ripristino di emergenza gestito

Per proteggere i dati e mantenere la business continuity durante le interruzioni a livello di regione, puoi configurare e utilizzare il ripristino di emergenza gestito da BigQuery per i dati e i workload di BigQuery.

Panoramica

BigQuery supporta scenari di ripristino di emergenza in caso di interruzione totale a livello di regione. Ripristino di emergenza di BigQuery si basa sulla replica dei set di dati tra regioni per gestire il failover dello spazio di archiviazione. Dopo aver creato una replica del set di dati in una regione secondaria, puoi controllare il comportamento di failover per il computing e lo spazio di archiviazione per mantenere la continuità aziendale durante un'interruzione del servizio. Dopo un failover, puoi accedere alla capacità di calcolo (slot) e ai set di dati replicati nella regione promossa. Il disaster recovery è supportato solo con la versione Enterprise Plus.

Il ripristino di emergenza gestito offre due opzioni di failover: failover completo e failover parziale. Un failover completo promuove immediatamente la prenotazione e le repliche dei set di dati della regione secondaria a regione principale. Questa azione viene eseguita anche se la regione principale attuale è offline e non attende la replica di dati non replicati. Per questo motivo, durante il failover completo può verificarsi una perdita di dati. Dopo un failover definitivo, potrebbe essere necessario eseguire nuovamente nella regione di destinazione tutti i job che hanno eseguito il commit dei dati nella regione di origine dopo il valore replication_time della replica. Durante un failover completo, potrebbero andare persi anche i controlli di accesso (ACL) dei set di dati, tra cui le viste autorizzate e le concessioni di accesso degli utenti, che non sono ancora stati replicati. Per evitare interruzioni a valle, includi i passaggi per la ricreazione delle ACL (ad esempio, utilizzando terraform apply) nei playbook di failover. A differenza di un failover definitivo, un failover temporaneo attende che tutte le modifiche alla prenotazione e al set di dati di cui è stato eseguito il commit nella regione principale vengano replicate nella regione secondaria prima di completare il processo di failover. Un failover soft richiede che siano disponibili sia la regione principale che quella secondaria. L'avvio di un failover soft imposta softFailoverStartTime per la prenotazione. Il valore softFailoverStartTime viene cancellato al completamento del failover temporaneo.

Per attivare ripristino di emergenza, devi creare una prenotazione della versione Enterprise Plus nella regione principale, ovvero la regione in cui si trova il set di dati prima del failover. La capacità di computing in standby nella regione accoppiata è inclusa nella prenotazione Enterprise Plus. Poi, colleghi un set di dati a questa prenotazione per attivare il failover per quel set di dati. Puoi collegare un set di dati a una prenotazione solo se il set di dati è stato sottoposto a backfill e ha le stesse località principali e secondarie accoppiate della prenotazione. Dopo aver collegato un set di dati a una prenotazione di failover, solo le prenotazioni Enterprise Plus possono scrivere in questi set di dati e non puoi eseguire una promozione della replica tra regioni sul set di dati. Puoi leggere dai set di dati collegati a una prenotazione di failover con qualsiasi modello di capacità. Per saperne di più sulle prenotazioni, consulta Introduzione alla gestione dei workload.

La capacità di computing della regione principale è disponibile nella regione secondaria subito dopo un failover. Questa disponibilità si applica alla tua baseline di prenotazione, indipendentemente dal fatto che venga utilizzata o meno.

Devi scegliere attivamente di eseguire il failover nell'ambito dei test o in risposta a un disastro reale. Non dovresti eseguire il failover più di una volta in un intervallo di 10 minuti. Negli scenari di replica dei dati, il backfill si riferisce al processo di compilazione di una replica di un set di dati con dati storici esistenti prima della creazione o dell'attivazione della replica. I set di dati devono completare il backfill prima di poter eseguire il failover sul set di dati.

Il seguente diagramma mostra l'architettura del ripristino di emergenza gestito:

Architettura di ripristino di emergenza gestito.

Limitazioni

Al ripristino di emergenza di BigQuery si applicano le seguenti limitazioni:

  • Ripristino di emergenza di BigQuery è soggetto alle stesse limitazioni della replica dei set di dati tra regioni.

  • Una prenotazione di failover può avere un massimo di 1000 set di dati collegati.

  • Non puoi convertire una prenotazione esistente in una prenotazione di failover se la prenotazione ha più di 1000 assegnazioni di prenotazione.

  • Se le query fanno riferimento a set di dati collegati a più prenotazioni di failover all'interno dello stesso progetto di amministrazione, tutte le prenotazioni devono utilizzare la stessa località secondaria.

  • Una volta collegato un set di dati a una prenotazione di failover, solo le prenotazioni Enterprise Plus possono scrivere in quel set di dati. Puoi leggere dai set di dati collegati utilizzando qualsiasi modello di capacità.

  • Per i set di dati che utilizzano il ripristino di emergenza, i job di caricamento ed estrazione non possono utilizzare il pool di slot condivisi senza costi. Devi creare un'assegnazione di prenotazione di tipo PIPELINE perché solo la versione Enterprise Plus supporta la scrittura in set di dati configurati per il disaster recovery.

  • Dopo un failover, la scalabilità automatica dipende dalla disponibilità della capacità di computing nella regione secondaria. Nella regione secondaria è disponibile solo la baseline della prenotazione.

  • Se l'errore di replica si verifica durante la creazione iniziale delle risorse, la prenotazione non viene creata nella regione secondaria e non è disponibile il failover, né hard né soft.

  • Il failover soft richiede che siano disponibili sia la regione principale che quella secondaria.

  • Non puoi avviare un failover soft se le modifiche alla configurazione della prenotazione non sono state replicate nella regione secondaria. Eventuali errori di replica, come una quota di slot insufficiente nella regione secondaria o problemi temporanei, impediscono l'avvio del failover soft.

  • Durante un failover soft attivo, non puoi aggiornare la prenotazione o i set di dati collegati, ma puoi comunque leggerli.

  • I job in esecuzione su una prenotazione di failover durante un failover parziale attivo potrebbero non utilizzare gli slot di prenotazione a causa di modifiche temporanee del routing durante l'operazione di failover. Questi job utilizzano gli slot di prenotazione prima dell'inizio del failover graduale e una volta completato.

  • Dopo un failover, le query pianificate non vengono reindirizzate automaticamente alla nuova località principale perché sono associate alla località specificata durante la creazione. Per riprendere le query pianificate, devi ricrearle nella nuova località principale.

  • La vista INFORMATION_SCHEMA.RESERVATIONS non include i dettagli del failover. Per elencare gli eventi di failover per le prenotazioni, esegui una query sulla vista INFORMATION_SCHEMA.FAILOVER_HISTORY.

  • La vista INFORMATION_SCHEMA.JOBS contiene la cronologia dei job solo per la regione in cui sono stati eseguiti. La cronologia dei job della regione principale non viene replicata nella regione secondaria. Dopo un failover, la cronologia dei job della regione principale non è visibile nella regione secondaria.

Località

Le seguenti regioni sono disponibili quando crei una prenotazione di failover:

Codice località Nome della regione Descrizione della regione
AU
AUSTRALIA-SOUTHEAST1 Sydney
AUSTRALIA-SOUTHEAST2 Melbourne
CA
NORTHAMERICA-NORTHEAST1 Montréal
NORTHAMERICA-NORTHEAST2 Toronto
DE
EUROPE-WEST3 Francoforte
EUROPE-WEST10 Berlino
EU
EU UE (multi-regione)
EUROPE-CENTRAL2 Varsavia
EUROPE-NORTH1 Finlandia
EUROPE-SOUTHWEST1 Madrid
EUROPE-WEST1 Belgio
EUROPE-WEST3 Francoforte
EUROPE-WEST4 Paesi Bassi
EUROPE-WEST8 Milano
EUROPE-WEST9 Parigi
IN
ASIA-SOUTH1 Mumbai
ASIA-SOUTH2 Delhi
US
US Stati Uniti (multi-regione)
US-CENTRAL1 Iowa
US-EAST1 Carolina del Sud
US-EAST4 Virginia del Nord
US-EAST5 Columbus
US-SOUTH1 Dallas
US-WEST1 Oregon
US-WEST2 Los Angeles
US-WEST3 Salt Lake City
US-WEST4 Las Vegas

Le coppie di regioni devono essere selezionate all'interno di AU, CA, DE, EU, IN o US. Ad esempio, una regione all'interno di US non può essere accoppiata a una regione all'interno di EU.

Se il set di dati BigQuery si trova in una località multiregionale, non puoi utilizzare le seguenti coppie di regioni. Questa limitazione è necessaria per garantire che la prenotazione e i dati di failover siano separati geograficamente dopo la replica. Per saperne di più sulle regioni contenute all'interno di multiregioni, consulta Multiregioni.

  • us-central1 - us multiregionale
  • us-west1 - us multiregionale
  • eu-west1 - eu multiregionale
  • eu-west4 - eu multiregionale

Prima di iniziare

  1. Verifica di disporre dell'autorizzazione IAM (Identity and Access Management) bigquery.reservations.update per aggiornare le prenotazioni.
  2. Verifica di avere set di dati esistenti configurati per la replica. Per saperne di più, consulta Replica un set di dati.

Replica turbo

Il disaster recovery utilizza la replica turbo per una replica dei dati più rapida tra le regioni, il che riduce il rischio di esposizione alla perdita di dati, riduce al minimo i tempi di inattività del servizio e contribuisce a supportare un servizio ininterrotto in seguito a un'interruzione a livello di regione.

La replica turbo non si applica all'operazione di backfill iniziale. Una volta completata l'operazione di backfill iniziale, la replica turbo mira a replicare i set di dati in una singola coppia di regioni di failover con una replica secondaria entro 15 minuti, a condizione che la quota di larghezza di banda non venga superata e non si verifichino errori dell'utente.

Recovery Time Objective

Un RTO (Recovery Time Objective) è il tempo target consentito per il ripristino in BigQuery in caso di emergenza. Per saperne di più sull'RTO, consulta Nozioni di base sulla RE del DR.Il ripristino di emergenza gestito ha un RTO di cinque minuti dopo l'avvio di un failover. A causa dell'RTO, la capacità è disponibile nella regione secondaria entro cinque minuti dall'avvio del processo di failover.

Recovery Point Objective

Un RPO (Recovery Point Objective) è il momento più recente da cui è necessario poter ripristinare i dati. Per saperne di più sull'RPO, consulta Nozioni di base sulla RE DR. Il ripristino di emergenza gestito ha un RPO definito per set di dati. L'RPO mira a mantenere la replica secondaria entro 15 minuti dalla replica principale. Per soddisfare questo RPO, non puoi superare la quota di larghezza di banda e non possono verificarsi errori degli utenti.

Quota

Devi disporre della capacità di computing scelta nella regione secondaria prima di configurare una prenotazione di failover. Se non è disponibile una quota nella regione secondaria, non puoi configurare o aggiornare la prenotazione. Per saperne di più, consulta Quote e limiti.

Considerazioni sulle quote per le prenotazioni di failover

Quando configuri il ripristino di emergenza gestito, gli slot di riferimento per una prenotazione di failover vengono allocati nella regione secondaria. Questi slot allocati vengono visualizzati come "utilizzati" nella pagina Quote e limiti di sistema della regione secondaria, anche se la prenotazione è inattiva e non è stato avviato alcun failover. Assicurati che il progetto di amministrazione disponga di una quota di slot sufficiente nella regione secondaria per soddisfare la capacità di riferimento della prenotazione di failover. Per saperne di più sugli slot allocati e sull'utilizzo della quota, consulta Informazioni sulle metriche degli slot.

La larghezza di banda della replica turbo ha una quota. Per saperne di più, consulta Quote e limiti.

Prezzi

La configurazione del ripristino di emergenza gestito richiede i seguenti piani tariffari:

  • Capacità di calcolo: devi acquistare la versione Enterprise Plus.

  • Replica turbo: il disaster recovery si basa sulla replica turbo durante la replica. L'addebito avviene in base ai byte fisici e per GiB fisico replicato. Per saperne di più, consulta Prezzi del trasferimento di dati per la replica turbo.

  • Spazio di archiviazione: i byte di archiviazione nella regione secondaria vengono fatturati allo stesso prezzo dei byte di archiviazione nella regione principale. Per saperne di più, consulta Prezzi di archiviazione.

I clienti devono pagare solo per la capacità di computing nella regione principale. La capacità di computing secondaria (basata sulla baseline della prenotazione) è disponibile nella regione secondaria senza costi aggiuntivi. Gli slot inattivi non possono utilizzare la capacità di computing secondaria, a meno che non sia stato eseguito il failover della prenotazione.

Se devi eseguire letture di dati obsoleti nella regione secondaria, devi acquistare capacità di computing aggiuntiva.

Il ripristino di emergenza gestito supporta la scalabilità fluida di BigQuery. Per garantire la fatturazione al secondo senza una durata minima dopo un failover, devi attivare la scalabilità fluida di BigQuery sia nella regione principale che in quella secondaria.

Crea o modifica una prenotazione Enterprise Plus

Prima di collegare un set di dati a una prenotazione, devi creare una prenotazione Enterprise Plus o modificare una prenotazione esistente e configurarla per il ripristino di emergenza.

Crea una prenotazione

Seleziona una delle seguenti opzioni:

Console

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nel menu di navigazione, fai clic su Workload Management.

  3. Fai clic su Crea prenotazione.

  4. Nel campo Nome prenotazione, inserisci un nome per la prenotazione.

  5. Nell'elenco Località, seleziona la località.

  6. Nell'elenco Versione, seleziona la versione Enterprise Plus.

  7. Nell'elenco Selettore dimensione massima prenotazione, seleziona la dimensione massima della prenotazione.

  8. (Facoltativo) Nel campo Slot di base, inserisci il numero di slot di base per la prenotazione.

    Il numero di slot con scalabilità automatica disponibili viene determinato sottraendo il valore Slot di riferimento dal valore Dimensione massima della prenotazione. Ad esempio, se crei una prenotazione con 100 slot di riferimento e una dimensione massima della prenotazione di 400, la prenotazione avrà 300 slot con scalabilità automatica. Per saperne di più sugli slot di base, consulta Utilizzo delle prenotazioni con slot di base e di scalabilità automatica.

  9. Nell'elenco Località secondaria, seleziona la località secondaria.

  10. Per disattivare la condivisione degli slot inattivi e utilizzare solo la capacità degli slot specificata, fai clic sul pulsante di attivazione/disattivazione Ignora slot inattivi.

  11. Per espandere la sezione Impostazioni avanzate, fai clic sulla freccia di espansione .

  12. (Facoltativo) Per impostare la concorrenza target dei job, fai clic sul pulsante di attivazione/disattivazione Ignora la concorrenza automatica target dei job, quindi inserisci un valore per Concorrenza target dei job. La suddivisione degli slot viene visualizzata nella tabella Stima dei costi. Nella tabella Riepilogo capacità viene visualizzato un riepilogo della prenotazione.

  13. Fai clic su Salva.

La nuova prenotazione è visibile nella scheda Prenotazioni slot.

SQL

Per creare una prenotazione, utilizza l'istruzione DDL (Data Definition Language) CREATE RESERVATION.

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nell'editor di query, inserisci la seguente istruzione:

    CREATE RESERVATION
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
OPTIONS (
  slot_capacity = NUMBER_OF_BASELINE_SLOTS,
  edition = ENTERPRISE_PLUS,
  secondary_location = SECONDARY_LOCATION);

    Sostituisci quanto segue:

    • ADMIN_PROJECT_ID: l'ID progetto del progetto di amministrazione proprietario della risorsa di prenotazione.
    • LOCATION: la località della prenotazione. Se selezioni una località BigQuery Omni, l'opzione della versione è limitata alla versione Enterprise.
    • RESERVATION_NAME: il nome della prenotazione.

      Il nome deve iniziare e terminare con una lettera minuscola o un numero e contenere solo lettere minuscole, numeri e trattini.

    • NUMBER_OF_BASELINE_SLOTS: il numero di slot di base da allocare alla prenotazione. Non puoi impostare l'opzione slot_capacity e l'opzione edition nella stessa prenotazione.
    • SECONDARY_LOCATION: la località secondaria della prenotazione. In caso di interruzione, verrà eseguito il failover di tutti i set di dati collegati a questa prenotazione in questa località.

  3. Fai clic su Esegui.

Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.

Modifica una prenotazione esistente

Seleziona una delle seguenti opzioni:

Console

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nel menu di navigazione, fai clic su Workload Management.

  3. Fai clic sulla scheda Prenotazioni slot.

  4. Trova la prenotazione che vuoi aggiornare.

  5. Fai clic su Azioni prenotazioni e poi su Modifica.

  6. Nel campo Località secondaria, inserisci la località secondaria.

  7. Fai clic su Salva.

SQL

Per aggiungere o modificare una località secondaria in una prenotazione, utilizza l'istruzione DDL ALTER RESERVATION SET OPTIONS.

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nell'editor di query, inserisci la seguente istruzione:

    ALTER RESERVATION
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
SET OPTIONS (
  secondary_location = SECONDARY_LOCATION);

    Sostituisci quanto segue:

    • ADMIN_PROJECT_ID: l'ID progetto del progetto di amministrazione proprietario della risorsa di prenotazione.
    • LOCATION: la località della prenotazione, ad esempio europe-west9.
    • RESERVATION_NAME: il nome della prenotazione. Il nome deve iniziare e terminare con una lettera minuscola o un numero e contenere solo lettere minuscole, numeri e trattini.
    • SECONDARY_LOCATION: la località secondaria della prenotazione. In caso di interruzione, verrà eseguito il failover di tutti i set di dati collegati a questa prenotazione in questa località.

  3. Fai clic su Esegui.

Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.

Collega un set di dati a una prenotazione

Per attivare ripristino di emergenza per la prenotazione creata in precedenza, completa i seguenti passaggi. Il set di dati deve essere già configurato per la replica nelle stesse regioni principale e secondaria della prenotazione. Per saperne di più, consulta Replica dei set di dati tra regioni.

Console

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nel menu di navigazione, fai clic su Workload Management.

  3. Fai clic sulla scheda Prenotazioni slot.

  4. Fai clic sulla prenotazione a cui vuoi collegare un set di dati.

  5. Fai clic sulla scheda Disaster recovery.

  6. Fai clic su Aggiungi set di dati di failover.

  7. Inserisci il nome del set di dati che vuoi associare alla prenotazione.

  8. Fai clic su Aggiungi.

SQL

Per collegare un set di dati a una prenotazione, utilizza l'istruzione DDL ALTER SCHEMA SET OPTIONS.

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nell'editor di query, inserisci la seguente istruzione:

    ALTER SCHEMA
  `DATASET_NAME`
SET OPTIONS (
  failover_reservation = ADMIN_PROJECT_ID.RESERVATION_NAME);

    Sostituisci quanto segue:

    • DATASET_NAME: il nome del set di dati.
    • ADMIN_PROJECT_ID.RESERVATION_NAME: il nome della prenotazione a cui vuoi associare il set di dati.

  3. Fai clic su Esegui.

Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.

Scollega un set di dati da una prenotazione

Per interrompere la gestione del comportamento di failover di un set di dati tramite una prenotazione, scollega il set di dati dalla prenotazione. Questa operazione non modifica la replica principale corrente del set di dati né rimuove le repliche esistenti. Per saperne di più sulla rimozione delle repliche del set di dati dopo lo scollegamento di un set di dati, consulta Rimuovi la replica del set di dati.

Console

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nel menu di navigazione, fai clic su Gestione dei workload, quindi sulla scheda Prenotazioni slot.

  3. Fai clic sulla prenotazione da cui vuoi scollegare un set di dati.

  4. Fai clic sulla scheda Disaster recovery.

  5. Espandi l'opzione Azioni per la replica principale del set di dati.

  6. Fai clic su Rimuovi.

SQL

Per scollegare un set di dati da una prenotazione, utilizza l'istruzione DDL ALTER SCHEMA SET OPTIONS.

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nell'editor di query, inserisci la seguente istruzione:

    ALTER SCHEMA
  `DATASET_NAME`
SET OPTIONS (
  failover_reservation = NULL);

    Sostituisci quanto segue:

    • DATASET_NAME: il nome del set di dati.

  3. Fai clic su Esegui.

Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.

Avvia un failover

In caso di interruzione a livello di regione, devi eseguire manualmente il failover della prenotazione nella località utilizzata dalla replica. Il failover della prenotazione include anche tutti i set di dati associati. Per eseguire manualmente il failover di una prenotazione, segui questi passaggi:

Console

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nel menu di navigazione, fai clic su Disaster recovery.

  3. Fai clic sul nome della prenotazione per cui vuoi eseguire il failover.

  4. Seleziona Modalità di failover forzata (valore predefinito) o Modalità di failover graduale.

  5. Fai clic su Failover.

SQL

Per aggiungere o modificare una località secondaria in una prenotazione, utilizza l'istruzione DDL ALTER RESERVATION SET OPTIONS e imposta is_primary su TRUE.

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nell'editor di query, inserisci la seguente istruzione:

    ALTER RESERVATION
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
SET OPTIONS (
  is_primary = TRUE, failover_mode=FAILOVER_MODE);

    Sostituisci quanto segue:

    • ADMIN_PROJECT_ID: l'ID progetto del progetto di amministrazione proprietario della risorsa di prenotazione.
    • LOCATION: la nuova località principale della prenotazione, ovvero la località secondaria corrente prima del failover, ad esempio europe-west9.
    • RESERVATION_NAME: il nome della prenotazione. Il nome deve iniziare e terminare con una lettera minuscola o un numero e contenere solo lettere minuscole, numeri e trattini.
    • PRIMARY_STATUS: uno stato booleano che dichiara se la prenotazione è la replica principale.
    • FAILOVER_MODE: un parametro facoltativo utilizzato per descrivere la modalità di failover. Può essere impostato su HARD o SOFT. Se questo parametro non viene specificato, viene utilizzato HARD per impostazione predefinita.

  3. Fai clic su Esegui.

Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.

Monitora replica

Puoi monitorare lo stato delle repliche dei set di dati tramite BigQuery, Cloud Monitoring o le viste INFORMATION_SCHEMA.

Per informazioni sulla creazione di avvisi su queste metriche, consulta Crea dashboard, grafici e avvisi.

Visualizza lo stato della replica con BigQuery

Per visualizzare lo stato e la latenza della replica per un set di dati nella consoleGoogle Cloud , segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Nel riquadro Explorer, espandi il progetto.

  3. Fai clic sul set di dati che vuoi monitorare.

  4. Nel riquadro dei dettagli del set di dati, fai clic sulla scheda Dettagli.

  5. Nella sezione Repliche, visualizza Latenza di replica e Stato. Per visualizzare ulteriori dettagli, incluso un grafico della latenza di replica, fai clic su Visualizza dettagli.

Visualizza lo stato della replica con Cloud Monitoring

BigQuery fornisce le seguenti metriche in Monitoring per aiutarti a monitorare lo stato della replica:

  • Latenza di replica: l'inattività dei dati nella regione secondaria replicati nell'ambito della replica tra regioni o del ripristino di emergenza gestito. Questa metrica funge da proxy per il Recovery Point Objective (RPO).
  • Byte in uscita dalla rete: il volume di dati fatturati (in byte) replicati dalla regione principale alla regione secondaria. Questa metrica ti aiuta a monitorare l'utilizzo della quota di larghezza di banda.

Per visualizzare queste metriche in Monitoring, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Monitoring.

    Vai a Monitoring

  2. Fai clic su Esplora metriche.

  3. Nel campo Seleziona una metrica, cerca e seleziona Set di dati BigQuery.

  4. Seleziona Latenza di replica (bigquery.googleapis.com/storage/replication/dataset_staleness) o Byte in uscita dalla rete (bigquery.googleapis.com/storage/replication/network_egress_bytes_count).

  5. Fai clic su Applica.

  6. Nella sezione Aggregazione, seleziona un metodo di aggregazione. Per la metrica della latenza di replica, ti consigliamo di selezionare 99° percentile. Questa aggregazione mostra meglio il rendimento nel caso peggiore rispetto alla media o ad altre aggregazioni.

  7. (Facoltativo) Per visualizzare le metriche per un set di dati o una regione secondaria specifici, fai clic su Aggiungi filtro, seleziona l'opzione dataset_id o location e poi inserisci un valore. Se replichi i dati in più regioni secondarie, puoi raggrupparli per località per visualizzare le metriche di ogni regione.

Visualizza lo stato della replica con INFORMATION_SCHEMA

Per determinare lo stato delle repliche, esegui una query sulla vista INFORMATION_SCHEMA.SCHEMATA_REPLICAS. Ad esempio:

SELECT
  schema_name,
  replica_name,
  creation_complete,
  replica_primary_assigned,
  replica_primary_assignment_complete
FROM
  `region-LOCATION`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
  schema_name="my_dataset"

La seguente query restituisce i job degli ultimi sette giorni che non andrebbero a buon fine se i relativi set di dati fossero set di dati di failover. Per eseguire query sui job in un'organizzazione, sostituisci INFORMATION_SCHEMA.JOBS con INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION e ometti jobs.query perché la vista INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION non include il testo della query:

SELECT
  jobs.project_id AS job_project_id,
  jobs.job_id,
  jobs.job_type,
  jobs.statement_type,
  jobs.reservation_id,
  jobs.edition,
  jobs.destination_table.project_id AS dataset_project_id,
  jobs.destination_table.dataset_id,
  jobs.destination_table.table_id,
  jobs.query
FROM
  `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.JOBS AS jobs
WHERE
  jobs.creation_time
    BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
    AND CURRENT_TIMESTAMP()
  AND jobs.destination_table.project_id = 'DATASET_PROJECT_ID'
  AND jobs.destination_table.dataset_id = 'DATASET_ID'
  AND (jobs.edition IS NULL OR jobs.edition != 'ENTERPRISE_PLUS');

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto in cui sono stati eseguiti i job.
  • LOCATION: la località.
  • DATASET_PROJECT_ID: l'ID progetto in cui si trova il set di dati di destinazione.
  • DATASET_ID: l'ID del set di dati che prevedi di collegare a una prenotazione di failover.

Passaggi successivi