Replica del set di dati tra regioni

Con la replica del set di dati BigQuery, puoi configurare la replica automatica di un set di dati tra due diverse regioni o più regioni.

Panoramica

Quando crei un set di dati in BigQuery, selezioni una o più regioni in cui sono archiviati i dati. Per regione si intende un insieme di data center all'interno di un'area geografica, mentre per più regioni si intende una grande area geografica contenente due o più regioni geografiche. I tuoi dati vengono archiviati in una delle regioni contenute.

BigQuery archivia sempre copie dei tuoi dati in due diverse zone Google Cloud all'interno della località del set di dati. Una zona è un'area di deployment per le risorse Google Cloud all'interno di una regione. In tutte le regioni, la replica tra zone usa scritture doppie sincrone. La selezione di una località multiregionale non fornisce la replica tra regioni o la ridondanza a livello di regione, quindi non vi è alcun aumento della disponibilità del set di dati in caso di interruzione di una regione. I dati vengono archiviati in un'unica regione all'interno della posizione geografica.

Per un'ulteriore ridondanza geografica, puoi replicare qualsiasi set di dati. BigQuery crea una replica secondaria del set di dati, situata in un'altra regione da te specificata. Questa replica viene poi replicata in modo asincrono tra due zone con l'altra regione, per un totale di quattro copie a livello di zona.

Replica del set di dati

Se replichi un set di dati, BigQuery archivia i dati nell'area geografica specificata.

  • Regione principale. Quando si crea un set di dati, BigQuery lo colloca nella regione principale.

  • Regione secondaria. Quando aggiungi una replica del set di dati, BigQuery posiziona la replica nella regione secondaria.

Inizialmente, la replica nella regione principale è la replica principale, mentre quella nella regione secondaria è la replica secondaria.

La replica principale è scrivibile e la replica secondaria è di sola lettura. Le scritture nella replica principale vengono replicate in modo asincrono nella replica secondaria. All'interno di ogni regione, i dati vengono archiviati in modo ridondante in due zone. Il traffico di rete non esce mai dalla rete Google Cloud.

Il seguente diagramma mostra la replica che si verifica quando un set di dati viene replicato:

La replica principale nella zona principale della regione 1 viene replicata contemporaneamente nelle zone primarie e secondarie della regione 2.

Se la regione principale è online, puoi passare manualmente alla replica secondaria. Per maggiori informazioni, consulta Promuovi la replica secondaria.

Prezzi

Per i set di dati replicati ti viene addebitato il costo relativo:

  • Spazio di archiviazione. I byte di archiviazione nella regione secondaria vengono fatturati come copia separata nella regione secondaria. Consulta i prezzi di archiviazione di BigQuery.
  • Replica dei dati. Per ulteriori informazioni sulle modalità di fatturazione per la replica dei dati, consulta Prezzi della replica dei dati.

Capacità di calcolo nella regione secondaria

Per eseguire job e query sulla replica nella regione secondaria, devi acquistare slot all'interno della regione secondaria o eseguire una query on demand.

Puoi utilizzare gli slot per eseguire query di sola lettura dalla replica secondaria. Se promuovi la replica secondaria come principale, puoi utilizzare questi slot anche per scrivere nella replica.

Puoi acquistare lo stesso numero di slot disponibile nell'area geografica principale o un numero diverso di slot. Acquistare meno slot potrebbe influire sulle prestazioni delle query.

Considerazioni sulla località

Prima di aggiungere una replica del set di dati, devi creare il set di dati iniziale da replicare in BigQuery se non esiste già. La località della replica aggiunta è impostata su quella specificata durante l'aggiunta della replica. La località della replica aggiunta deve essere diversa da quella del set di dati iniziale. Ciò significa che i dati nel tuo set di dati vengono replicati continuamente tra la località in cui è stato creato e quella della replica. Per le repliche che richiedono la colocation, ad esempio viste, viste materializzate o tabelle esterne non BigLake, l'aggiunta di una replica in una località diversa o non compatibile con la località dei dati di origine potrebbe causare errori del job.

Quando i clienti replicano un set di dati in più regioni, BigQuery assicura che i dati si trovino solo nelle località in cui sono state create le repliche.

Requisiti di colocation

L'utilizzo della replica del set di dati dipende dai seguenti requisiti di colocation.

Cloud Storage

L'esecuzione di query sui dati su Cloud Storage richiede che il bucket Cloud Storage si trovi nella stessa posizione della replica. Utilizza le considerazioni sulla posizione delle tabelle esterne quando decidi dove posizionare la replica.

Limitazioni

La replica del set di dati BigQuery è soggetta alle seguenti limitazioni:

  • I dati nei flussi di cui non è stato eseguito il commit non vengono replicati nella replica secondaria se la tabella viene scritta con l'API BigQuery Storage Write. La replica dei flussi di dati dall'API BigQuery Storage Write o da tabledata.insertAll è il metodo ottimale e potrebbe comportare un ritardo di replica elevato.
  • L'API BigQuery Storage Read non supporta la lettura dalle tabelle contenute nella replica del set di dati secondario. Per leggere da una tabella contenuta all'interno della replica secondaria, è necessario prima promuovere la replica secondaria come replica principale.
  • Le tabelle inserite in BigQuery tramite Datastream tramite Change Data Capture non sono supportate.
  • La replica e il passaggio sono gestiti tramite istruzioni DDL (Data Definition Language) SQL.
  • Hai un limite di una replica di ogni set di dati per ogni regione o più regioni. Non puoi creare due repliche secondarie dello stesso set di dati nella stessa regione di destinazione.
  • Le risorse all'interno delle repliche sono soggette alle limitazioni descritte in Comportamento delle risorse.
  • I tag di criteri e i criteri sui dati associati non vengono replicati nella replica secondaria. Tutte le query che fanno riferimento a colonne con tag di criteri in regioni diverse da quella originale non andranno a buon fine, anche se la replica viene promossa.
  • Lo spostamento nel tempo è disponibile solo nella replica secondaria dopo il completamento della creazione della replica secondaria.
  • Puoi replicare solo un set di dati con meno di 100.000 tabelle.
  • Puoi aggiungere un massimo di 4 repliche (poi eliminate) nella stessa area geografica per set di dati al giorno.
  • La larghezza di banda di replica per l'operazione di copia iniziale è limitata a 1 GB/secondo fisico per progetto per coppia di continenti. La replica a questa velocità non è garantita.
  • Non è possibile eseguire query nelle tabelle con chiavi di crittografia gestite dal cliente (CMEK) applicate nella regione secondaria se il valore replica_kms_key non è configurato.
  • Le tabelle BigLake non sono supportate.

Comportamento delle risorse

Le seguenti operazioni non sono supportate sulle risorse all'interno della replica secondaria:

Se devi creare una copia di una risorsa in una replica secondaria, devi copiare la risorsa o eseguire query e quindi materializzare i risultati al di fuori della replica secondaria. Ad esempio, utilizza CREATE TABLE AS SELECT per creare una nuova risorsa dalla risorsa di replica secondaria.

Le repliche primarie e secondarie sono soggette alle seguenti differenze:

Replica principale regione 1 Replica secondaria regione 2 Note
Tabella BigLake Tabella BigLake Non supportati.
Tabella esterna Tabella esterna Viene replicata solo la definizione della tabella esterna. La query non riesce quando il bucket Cloud Storage non si trova nella stessa località di una replica.
Visualizzazione logica Visualizzazione logica Le viste logiche che fanno riferimento a un set di dati o a una risorsa che non si trovano nella stessa località della visualizzazione logica non funzionano se viene eseguita una query.
Tabella gestita Tabella gestita Nessuna differenza.
Vista materializzata Vista materializzata Se una tabella di riferimento non si trova nella stessa regione della vista materializzata, la query non riesce. Le viste materializzate replicate potrebbero risultare inattive sopra il valore inattivo massimo della vista.
personalizzato personalizzato Archiviate come tabelle gestite.
Funzione remota Funzione remota Le connessioni operano a livello di regione. Le funzioni remote che fanno riferimento a un set di dati o a una risorsa (connessione) che non si trovano nella stessa località della funzione remota non vengono eseguite quando vengono eseguite.
Routine Funzione definita dall'utente o stored procedure Le routine che fanno riferimento a un set di dati o a una risorsa che non si trovano nella stessa località della routine non riescono quando vengono eseguite. Qualsiasi routine che fa riferimento a una connessione, ad esempio funzioni remote, non funziona al di fuori della regione di origine.
Criterio di accesso alle righe Criterio di accesso alle righe Nessuna differenza.
Cerca nell'indice Cerca nell'indice Non replicato.
Stored procedure Stored procedure Le stored procedure che fanno riferimento a un set di dati o a una risorsa che non si trovano nella stessa località della stored procedure hanno esito negativo quando vengono eseguite.
Clone della tabella Tabella gestita Fatturato come copia approfondita nella replica secondaria.
Snapshot tabella Snapshot tabella Fatturato come copia approfondita nella replica secondaria.
Funzione con valori di tabella (TVF) TVF I TVF che fanno riferimento a un set di dati o a una risorsa che non si trovano nella stessa località del TVF hanno esito negativo quando vengono eseguiti.
Funzioni definite dall'utente Funzioni definite dall'utente Le funzioni definite dall'utente che fanno riferimento a un set di dati o a una risorsa che non si trovano nella stessa località della funzione definita dall'utente non riescono quando vengono eseguite.

Scenari di interruzione

La replica tra regioni non è destinata a essere utilizzata come piano di ripristino di emergenza durante un'interruzione totale in tutte le regioni. In caso di interruzione totale di una regione nella regione della replica principale, non puoi promuovere la replica secondaria. Poiché le repliche secondarie sono di sola lettura, non puoi eseguire job di scrittura sulla replica secondaria e non puoi promuovere la regione secondaria finché non viene ripristinata la regione della replica principale.

La tabella seguente spiega l'impatto delle interruzioni totali nelle regioni sui dati replicati:

Regione 1 Regione 2 Regione interruzione Impatto
Replica principale Replica secondaria Regione 2 I job di sola lettura in esecuzione nella regione 2 rispetto alla replica secondaria non riescono.
Replica principale Replica secondaria Regione 1 Tutti i job in esecuzione nella regione 1 non riescono. I job di sola lettura continuano a essere eseguiti nella regione 2, dove si trova la replica secondaria. I contenuti della regione 2 sono inattivi fino a quando non viene sincronizzata con la regione 1.

Usa replica del set di dati

Questa sezione descrive come replicare un set di dati, promuovere la replica secondaria ed eseguire job di lettura BigQuery nella regione secondaria.

Autorizzazioni obbligatorie

Per ottenere le autorizzazioni necessarie per gestire le repliche, chiedi all'amministratore di concederti l'autorizzazione bigquery.datasets.update.

Replica di un set di dati

Per replicare un set di dati, utilizza l'istruzione DDL ALTER SCHEMA ADD REPLICA.

Puoi aggiungere una replica a qualsiasi set di dati che si trova in una o più regioni che non sono già replicate in quella singola regione. Dopo aver aggiunto una replica, il completamento dell'operazione di copia iniziale richiede del tempo. Puoi comunque eseguire query che fanno riferimento alla replica principale durante la replica dei dati, senza alcuna riduzione della capacità di elaborazione delle query. Non puoi replicare i dati all'interno delle località geografiche all'interno di una multiregione.

L'esempio seguente crea un set di dati denominato my_dataset nella località multiregionale US, quindi aggiunge una replica denominata us-east4:

-- Create the primary replica in the US multi-region.
CREATE SCHEMA my_dataset OPTIONS(location='us');

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-east4`
OPTIONS(location='us-east4');

Per verificare il completamento della creazione della replica secondaria, puoi eseguire una query sulla colonna creation_complete nella vista INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Promuovi la replica secondaria

Se la regione principale è online, puoi promuovere la replica secondaria. Con la promozione, la replica secondaria diventa principale scrivibile. Questa operazione viene completata entro pochi secondi se la replica secondaria viene raggiunta con la replica principale. Se la replica secondaria non viene raggiunta, la promozione non può essere completata finché non viene utilizzata. La replica secondaria non può essere promossa a principale se si è verificata un'interruzione nella regione contenente quella principale.

Tieni presente quanto segue:

  • Tutte le scritture nelle tabelle restituiscono errori durante l'elaborazione della promozione. La replica principale precedente diventa non scrivibile subito quando inizia la promozione.
  • Le tabelle che non sono state replicate completamente al momento dell'avvio della promozione restituiscono letture obsolete.

Per promuovere una replica come replica principale, utilizza l'istruzione DDL ALTER SCHEMA SET OPTIONS e imposta l'opzione primary_replica.

Nota: - Devi impostare esplicitamente la località del job sulla regione secondaria nelle impostazioni della query. Consulta l'articolo Specificare le località in BigQuery.

L'esempio seguente promuove la replica us-east4 come principale:

ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = 'us-east4')

Per verificare quando la replica secondaria è stata promossa, puoi eseguire una query sulla colonna replica_primary_assignment_complete nella vista INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Rimuovi una replica del set di dati

Per rimuovere una replica e interrompere la replica del set di dati, utilizza l'istruzione DDL ALTER SCHEMA DROP REPLICA.

L'esempio seguente rimuove la replica us:

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

Devi prima eliminare eventuali repliche secondarie per eliminare l'intero set di dati. Se elimini l'intero set di dati, ad esempio utilizzando l'DROP SCHEMAistruzione, senza eliminare tutte le repliche secondarie, viene visualizzato un errore.

Elenca repliche del set di dati

Per elencare le repliche del set di dati in un progetto, esegui una query sulla vista INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Migrazione dei set di dati

Puoi utilizzare la replica del set di dati tra regioni per eseguire la migrazione dei tuoi set di dati da una regione a un'altra. L'esempio seguente mostra il processo di migrazione del set di dati my_migration esistente dalla località multiregionale US alla località multiregionale EU utilizzando la replica tra regioni.

Replica il set di dati

Per iniziare il processo di migrazione, devi prima replicare il set di dati nella regione in cui vuoi eseguire la migrazione dei dati. In questo scenario, stai eseguendo la migrazione del set di dati my_migration alla località multiregionale EU.

-- Create a replica in the secondary region.
ALTER SCHEMA my_migration
ADD REPLICA `eu`
OPTIONS(location='eu');

Viene creata una replica secondaria denominata eu nella località multiregionale EU. La replica principale è il set di dati my_migration nella località multiregionale US.

Promuovi la replica secondaria

Per continuare a eseguire la migrazione del set di dati nella località multiregionale EU, promuovi la replica secondaria:

ALTER SCHEMA my_migration SET OPTIONS(primary_replica = 'eu')

Una volta completata la promozione, eu è la replica principale. È una replica scrivibile.

Completare la migrazione

Per completare la migrazione da US a più regioni EU, elimina la replica us. Questo passaggio non è obbligatorio, ma è utile se non hai bisogno di una replica del set di dati che vada oltre le tue esigenze di migrazione.

ALTER SCHEMA my_migration
DROP REPLICA IF EXISTS us;

Il set di dati si trova nella località multiregionale EU e non sono presenti repliche del set di dati my_migration. Hai eseguito correttamente la migrazione del set di dati in EU. L'elenco completo delle risorse di cui viene eseguita la migrazione è disponibile in Comportamento delle risorse.

Chiavi di crittografia gestite dal cliente (CMEK)

Le chiavi Cloud Key Management Service gestite dal cliente non vengono replicate automaticamente quando crei una replica secondaria. Per mantenere la crittografia sul set di dati replicato, devi impostare replica_kms_key per la località della replica aggiunta. Puoi impostare replica_kms_key utilizzando l'istruzione DDL ALTER SCHEMA ADD REPLICA.

La replica dei set di dati con CMEK si comporta come descritto nei seguenti scenari:

  • Se il set di dati di origine ha un valore default_kms_key, devi fornire un replica_kms_key creato nella regione del set di dati di replica quando utilizzi l'istruzione DDL ALTER SCHEMA ADD REPLICA.

  • Se per il set di dati di origine non è impostato un valore per default_kms_key, non puoi impostare replica_kms_key.

  • Se utilizzi la rotazione della chiave Cloud KMS (o entrambi) su default_kms_key o replica_kms_key, è ancora possibile eseguire query sul set di dati replicato dopo la rotazione della chiave.

    • La rotazione della chiave nell'area geografica principale aggiorna la versione della chiave solo nelle tabelle create dopo la rotazione. Le tabelle esistenti prima della rotazione della chiave utilizzano ancora la versione della chiave impostata prima della rotazione.
    • La rotazione della chiave nella regione secondaria aggiorna tutte le tabelle nella replica secondaria alla nuova versione della chiave.
    • Se imposti la replica principale come replica secondaria, tutte le tabelle nella replica secondaria (in precedenza replica principale) verranno aggiornate alla nuova versione della chiave.
    • Se viene eliminata la versione della chiave impostata sulle tabelle nella replica primaria prima della rotazione della chiave, è possibile eseguire query su tutte le tabelle che utilizzano ancora la versione della chiave impostata prima della rotazione della chiave finché non viene aggiornata la versione della chiave. Per aggiornare la versione della chiave, la versione precedente della chiave deve essere attiva (non disabilitata o eliminata).

  • Se il set di dati di origine non ha un valore impostato per default_kms_key, ma sono presenti singole tabelle nel set di dati di origine con CMEK applicata, non è possibile eseguire query su queste tabelle nel set di dati replicato. Per eseguire query sulle tabelle:

    • Aggiungi un valore default_kms_key per il set di dati di origine.
    • Quando crei una nuova replica utilizzando l'istruzione DDL ALTER SCHEMA ADD REPLICA, imposta un valore per l'opzione replica_kms_key. È possibile eseguire query sulle tabelle CMEK nella regione di destinazione.

    Tutte le tabelle CMEK nella regione di destinazione utilizzano lo stesso replica_kms_key, indipendentemente dalla chiave utilizzata nella regione di origine.

Crea una replica con CMEK

L'esempio seguente crea una replica nella regione us-west1 con un valore replica_kms_key impostato. Per la chiave CMEK, concedi l'autorizzazione dell'account di servizio BigQuery per criptare e decriptare.

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-west1`
OPTIONS(location='us-west1',
  replica_kms_key='my_us_west1_kms_key_name');

Limitazioni CMEK

La replica dei set di dati con CMEK applicata è soggetta alle seguenti limitazioni:

  • Non puoi aggiornare la chiave Cloud KMS replicata dopo aver creato la replica.

  • Non puoi aggiornare il valore default_kms_key sul set di dati di origine dopo aver creato le repliche del set di dati.

  • Se il valore replica_kms_key fornito non è valido nella regione di destinazione, il set di dati non verrà replicato.

  • Le tabelle criptate con CMEK replicate nella regione di destinazione sono visibili, ma non possono essere eseguite query o scritte perché la CMEK di origine non è riconosciuta nella regione di destinazione.

Passaggi successivi