Replica del set di dati tra regioni

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

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

Panoramica

Quando crei un set di dati in BigQuery, selezioni la regione o in cui sono archiviati i dati. Una regione è una raccolta di dati centri all'interno di un'area geografica, mentre per più regioni si intende una grande che contiene due o più regioni geografiche. I tuoi dati vengono archiviati in uno di le regioni contenute e non viene replicato all'interno della località multiregionale. Per ulteriori informazioni su regioni e regioni multiple, consulta BigQuery di località.

BigQuery archivia sempre copie dei tuoi dati in due diversi 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 le zone utilizza la doppia scrittura sincrona. Selezione di una località multiregionale non fornisce la replica tra regioni o la ridondanza a livello di regione, quindi non esiste di aumento della disponibilità del set di dati in caso di interruzione del servizio a livello di regione. I dati sono in una singola regione all'interno della posizione geografica.

Per ulteriore ridondanza geografica, puoi replicare qualsiasi set di dati. BigQuery crea una replica secondaria del set di dati, che si trova in un'altra regione da te specificata. Questa replica viene quindi 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 regione specificata.

• Regione principale. Quando crei un set di dati, BigQuery posiziona il set di dati nella regione principale.

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

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

La replica principale è scrivibile e la replica secondaria è di sola lettura. Scritture nella replica principale vengono replicate in modo asincrono nella replica secondaria. All'interno di ogni regione, i dati sono archiviati in modo ridondante in due zone. 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:

Se la regione principale è online, puoi passare manualmente a quella secondaria replica. Per ulteriori informazioni, consulta la sezione Promuovere l'attività secondaria replica.

Prezzi

Ti viene addebitato quanto segue per i set di dati replicati:

• Spazio di archiviazione. I byte di archiviazione nella regione secondaria vengono fatturati come copia nella regione secondaria. Vedi Archiviazione BigQuery pricing.
• Replica dei dati. Per ulteriori informazioni sulla fatturazione relativa ai dati, consulta la sezione Replica dei dati pricing.

Capacità di calcolo nella regione secondaria

Per eseguire job e query sulla replica nella regione secondaria, devi acquistare slot nella regione secondaria o eseguire un delle query on demand.

Puoi utilizzare gli slot per eseguire query di sola lettura dall'istanza secondaria replica. Se promuovi la replica secondaria a principale, puoi utilizzare questi slot per scrivere nella replica.

Puoi acquistare lo stesso numero di slot che hai nell'offerta principale regione o un numero diverso di slot. Se acquisti meno slot, 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 la località della replica aggiunta sia impostata su quella specificata aggiungendo la replica. La località della replica aggiunta deve essere diversa dalla del set di dati iniziale. Ciò significa che i dati del tuo set di dati vengono replicati continuamente tra la località in cui è stato creato il set di dati località della replica. Per le repliche che richiedono la colocation, come le viste, viste materializzate o tabelle esterne non BigLake, aggiungendo una replica da una località diversa da quella dei dati di origine o non compatibile con quella posizione potrebbe causare errori nel 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'uso 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 sia allocato alla replica. Utilizza la posizione delle tabelle esterne considerazioni al momento di decidere 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 nel replica secondaria se la tabella è scritta con API BigQuery Storage Writer. Replica dei flussi di dati o i dati provenienti dall'API BigQuery StorageWrite tabledata.insertAll fa il "best effort" e potrebbe notare un ritardo di replica elevato.
• L'API BigQuery Storage Read non supporta la lettura dalle tabelle contenute nella replica del set di dati secondario. A legge da una tabella contenuta nella replica secondaria, la replica principale deve essere prima promossa.
• Tabelle inserite tramite Da Datastream a BigQuery utilizzando Modifica acquisizione dati non è supportato.
• La replica e il cambio sono gestiti mediante il linguaggio di definizione dei dati SQL (DDL) estratti conto.
• Esiste un limite di una replica di ogni set di dati per ogni regione in più regioni. Non puoi creare due repliche secondarie dello stesso set di dati in nella stessa regione di destinazione.
• Le risorse all'interno delle repliche sono soggette alle limitazioni descritte in Comportamento delle risorse:
• Tag di criteri e i criteri dei dati associati non vengono replicati nella replica secondaria. Qualsiasi che fanno riferimento a colonne con tag di criteri in regioni diverse dalla regione originale non riesce anche se la replica viene promossa.
• Viaggio nel tempo è disponibile solo nella scuola secondaria al termine della creazione della replica secondaria.
• Puoi replicare solo un set di dati con meno di 100.000 tabelle.
• Puoi aggiungere al massimo 4 repliche aggiunte (poi eliminate) alla stessa regione per set di dati al giorno.
• La larghezza di banda di replica per l'operazione di copia iniziale è limitata a 1 unità fisica GB/secondo per progetto per coppia di continenti. La replica a questa velocità non è garantito.
• Tabelle con crittografia gestita dal cliente chiavi (CMEK) applicate non sono interrogabile nella regione secondaria se il valore replica_kms_key non è configurato.
• Le tabelle BigLake non sono supportate.
• Se stai configurando la replica dei dati per il ripristino di emergenza, non puoi configurare le seguenti coppie di regioni:
  .
  • us-central1 - us (più regioni)
  • us-west1 - us (più regioni)
  • eu-west1 - eu (più regioni)
  • eu-west4 - eu (più regioni)

Comportamento delle risorse

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

• Creazione di un clone di una tabella
• Creazione di uno snapshot della tabella

Se devi creare una copia di una risorsa in una replica secondaria, devi copiare la risorsa o eseguire una query, quindi materializzare i risultati all'esterno della replica secondaria. Ad esempio, usa CREA TABELLA COME SELEZIONA per creare una nuova risorsa dalla risorsa di replica secondaria.

Le repliche primarie e secondarie sono soggette alle seguenti differenze:

Replica principale della regione 1	Replica secondaria della regione 2	Note
Tabella BigLake	Tabella BigLake	Non supportati.
Tabella esterna	Tabella esterna	Viene replicata solo la definizione della tabella esterna. La query ha esito negativo quando il bucket Cloud Storage non è collocato nella stessa località di replica.
Vista logica	Vista logica	Viste logiche che fanno riferimento a un set di dati o a una risorsa che non si trova nella stessa posizione della vista logica non riesce quando viene eseguita una query.
Tabella gestita	Tabella gestita	Nessuna differenza.
Visualizzazione materializzata	Visualizzazione materializzata	Se viene fatto riferimento non si trova nella stessa regione della vista materializzata, la query ha esito negativo. Le viste materializzate replicate potrebbero presentare problemi di mancato aggiornamento al di sopra del valore max della vista di inattività.
Modello	Modello	Archiviati come tabelle gestite.
Funzione remota	Funzione remota	Le connessioni sono a livello di regione. Le funzioni remote che fanno riferimento a un set di dati (connessione) che non si trova nella stessa località la funzione remota ha esito negativo durante l'esecuzione.
Routine	Funzione definita dall'utente o stored procedure	Routine che fanno riferimento a un set di dati o a una risorsa che non si trova in la stessa posizione della routine ha esito negativo durante l'esecuzione. Qualsiasi routine fa riferimento a una connessione, ad esempio funzioni remote, non funziona al di fuori la regione di origine.
Criterio di accesso alle righe	Criterio di accesso alle righe	Nessuna differenza.
Cerca indice	Cerca indice	Non replicato.
Stored procedure	Stored procedure	Stored procedure che fanno riferimento a un set di dati o a una risorsa che non si trova nello stesso posizione perché la stored procedure ha esito negativo durante l'esecuzione.
Clone da tavola	Tabella gestita	Fatturazione come copia diretta nella replica secondaria.
Snapshot tabella	Snapshot tabella	Fatturazione come copia diretta nella replica secondaria.
Funzione con valore di tabella (TVF)	TVF	TVF che fanno riferimento a un set di dati o a una risorsa che non si trova stessa posizione dell'errore TVF non riesce durante l'esecuzione.
Funzioni definite dall'utente	Funzioni definite dall'utente	Funzioni definite dall'utente che fanno riferimento a un set di dati o a una risorsa che non si trova stessa posizione della funzione definita dall'utente non riesce durante l'esecuzione.

Scenari di interruzione del servizio

La replica tra regioni non è destinata a essere utilizzata come piano di ripristino di emergenza durante un'interruzione in una regione totale. In caso di interruzione totale della regione regione della replica principale, non puoi promuovere la replica secondaria. Poiché le repliche secondarie sono di sola lettura, non puoi eseguire job di scrittura e non può promuovere la regione secondaria fino a quando e la regione in cui l'accesso è stato ripristinato. Per ulteriori informazioni sulla preparazione per il ripristino di emergenza, consulta Ripristino di emergenza gestito.

La tabella seguente spiega l'impatto delle interruzioni totali a livello di regione sui tuoi i 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 sulla 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 in regione 2 in cui si trova la replica secondaria. I contenuti di La regione 2 è obsoleta finché non viene sincronizzata con la regione 1.

Usa replica del set di dati

Questa sezione descrive come replicare un set di dati, promuovere l'oggetto secondario ed eseguire job di lettura BigQuery nella regione secondaria.

Autorizzazioni obbligatorie

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

Replica un set di dati

Per replicare un set di dati, utilizza ALTER SCHEMA ADD REPLICA Istruzione DDL.

Puoi aggiungere una replica a qualsiasi set di dati che si trova in una o più regioni che non è già replicato in quella regione o in quella multiregione. Dopo aver aggiunto un parametro la replica iniziale, il completamento dell'operazione di copia iniziale richiede tempo. Puoi ancora eseguire query che fanno riferimento alla replica principale mentre i dati vengono replicati senza riduzione della capacità di elaborazione delle query. Non puoi replicare i dati le località geografiche all'interno di più regioni.

L'esempio seguente crea un set di dati denominato my_dataset nel campo us-central1 e aggiunge una replica nella regione us-east4:

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

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

Per verificare se la replica secondaria è stata creata correttamente, puoi: esegui una query sulla colonna creation_complete nella INFORMATION_SCHEMA.SCHEMATA_REPLICAS vista.

Promuovi la replica secondaria

Se la regione principale è online, puoi promuovere la replica secondaria. La promozione imposta la replica secondaria come principale scrivibile. Questo l'operazione viene completata entro pochi secondi se la replica secondaria viene con la replica principale. Se la replica secondaria non viene aggiornata, la promozione non può essere completata fino a quando non viene ricaricata. La replica secondaria non può essere promosso a principale se nella regione in cui è presente l'istanza principale si è verificata un'interruzione.

Tieni presente quanto segue:

• Tutte le scritture nelle tabelle restituiscono errori durante l'elaborazione della promozione. Le vecchie primarie diventa non scrivibile subito all'inizio della promozione.
• Tabelle che non sono completamente replicate al momento dell'inizio della promozione restituiscono letture inattive.

Per promuovere una replica a replica principale, utilizza il DDL ALTER SCHEMA SET OPTIONS dichiarazione e imposta l'opzione primary_replica.

Tieni presente quanto segue: - Devi impostare esplicitamente la località del job sulla regione secondaria nella query impostazioni. Consulta Specifica delle 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 se la replica secondaria è stata promossa, puoi: esegui una query sulla colonna replica_primary_assignment_complete nella INFORMATION_SCHEMA.SCHEMATA_REPLICAS vista.

Rimuovi una replica del set di dati

Per rimuovere una replica e interrompere la replica del set di dati, utilizza il metodo ALTER SCHEMA DROP REPLICA Istruzione DDL.

L'esempio seguente rimuove la replica us:

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

Devi prima rilasciare eventuali repliche secondarie per eliminare l'intero set di dati. Se Eliminare l'intero set di dati, ad esempio utilizzando l'istruzione DROP SCHEMA, senza l'eliminazione di 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 INFORMATION_SCHEMA.SCHEMATA_REPLICAS vista.

Esegui la migrazione dei set di dati

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

Replica il set di dati

Per iniziare il processo di migrazione, replica prima il set di dati nella regione in cui in cui eseguire la migrazione dei dati. In questo scenario, eseguirai la migrazione my_migration nella località multiregionale EU.

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

Questa operazione crea una replica secondaria denominata eu nell'area multiregionale EU. La replica principale è il set di dati my_migration nell'area multiregionale US.

Promuovi la replica secondaria

Per continuare la migrazione del set di dati nell'area multiregionale EU, promuovi la replica secondaria:

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

Al termine della promozione, eu sarà la replica principale. È accessibile in scrittura replica.

Completare la migrazione

Per completare la migrazione dall'area multiregionale US all'area multiregionale EU, elimina la replica us. Questo passaggio non è obbligatorio, ma è utile se non 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 nell'area multiregionale EU e non esistono repliche di il set di dati my_migration. Hai eseguito correttamente la migrazione del set di dati EU (più regioni). È disponibile l'elenco completo delle risorse di cui viene eseguita la migrazione in Comportamento delle risorse.

Chiavi di crittografia gestite dal cliente (CMEK)

Chiavi Cloud Key Management Service gestite dal cliente non vengono replicati automaticamente quando crei una replica secondaria. Nell'ordine 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 con ALTER SCHEMA ADD REPLICA DDL Informativa.

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 valore replica_kms_key creato nella regione del set di dati della replica quando utilizzi l'istruzione DDL ALTER SCHEMA ADD REPLICA.

• Se nel set di dati di origine non è impostato un valore per default_kms_key, non può impostare replica_kms_key.

• Se utilizzi la rotazione delle chiavi Cloud KMS su una (o entrambe) delle default_kms_key o replica_kms_key il set di dati replicato è ancora query dopo la rotazione della chiave.

  • La rotazione della chiave nella regione principale aggiorna la versione della chiave solo nelle tabelle create dopo la rotazione, per le tabelle esistenti prima della rotazione della chiave viene della chiave impostata prima della rotazione.
  • Rotazione della chiave nella regione secondaria aggiorna tutte le tabelle nella replica secondaria alla nuova versione della chiave.
  • Il passaggio della replica principale alla replica secondaria aggiorna tutte le tabelle nella replica secondaria (in precedenza replica principale) alla nuova versione della chiave.
  • Se la versione della chiave impostata nelle tabelle della replica primaria prima della rotazione della chiave viene eliminata, tutte le tabelle che utilizzano ancora la versione della chiave impostata prima della rotazione della chiave non è possibile eseguire query finché la versione della chiave non viene aggiornata. Per aggiornare la chiave la versione precedente della chiave deve essere attiva (non disabilitata o eliminata).

• Se nel set di dati di origine non è impostato un valore per default_kms_key, ma sono presenti singole tabelle nel set di dati di origine a cui è stata applicata una CMEK, quelle non è possibile eseguire query nel set di dati replicato. Per eseguire query sulle tabelle, esegui seguenti:

  • Aggiungi un valore default_kms_key per il set di dati di origine.
  • Quando crei un 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, a prescindere 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 di replica_kms_key impostato. Per la chiave CMEK, concedi la Autorizzazione per l'account di servizio BigQuery per crittografare 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 che la replica è è stato creato.

• Non puoi aggiornare il valore default_kms_key nel set di dati di origine dopo la creazione delle repliche del set di dati.

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

• Le tabelle criptate con CMEK replicate nella regione di destinazione sono visibili, ma non è possibile eseguire query o scrivere in perché la CMEK di origine non è riconosciuta nel regione di destinazione.

Passaggi successivi

• Scopri come utilizzare Prenotazioni BigQuery.
• Informazioni su Funzionalità di affidabilità di BigQuery.