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

Nota: per fornire feedback o porre domande relative a questa release di anteprima, contatta [e-mail].

Con la replica dei set di dati BigQuery, puoi configurare la replica automatica di un set di dati tra due regioni diverse o multiregioni.

Panoramica

Quando crei un set di dati in BigQuery, selezioni la regione o la regione con più regioni in cui sono archiviati i dati. Una regione è un insieme di data center all'interno di un'area geografica, mentre una più regioni è una vasta area geografica che contiene due o più regioni geografiche. I dati vengono archiviati in una delle regioni contenute e non vengono replicati all'interno della regione multipla. Per ulteriori informazioni su regioni e multiregioni, consulta Località di BigQuery.

BigQuery archivia sempre copie dei dati in due diverse zone Google Cloud all'interno della posizione 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 utilizza le doppie scritture sincrone. La selezione di una località con più regioni non fornisce la replica tra regioni o la ridondanza a livello di regione, pertanto non avviene un aumento della disponibilità dei set di dati in caso di interruzione del servizio a livello di regione. I dati vengono archiviati in un'unica regione all'interno della posizione geografica.

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

Replica dei set di dati

Se replichi un set di dati, BigQuery archivia i dati nella regione specificata.

• Regione principale. Quando crei un set di dati per la prima volta, BigQuery lo colloca nella regione principale.

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

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

La replica principale è scrivibile e quella secondaria è di sola lettura. Le scritture alla 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 viene replicato un set di dati:

Se la regione principale è online, puoi passare manualmente alla replica secondaria. Per ulteriori informazioni, consulta Eseguire il passaggio della replica secondaria.

Prezzi

Per i set di dati replicati ti viene addebitato quanto segue:

• Spazio di archiviazione. I byte di spazio di archiviazione nella regione secondaria vengono fatturati come copia distinta nella regione secondaria. Consulta i prezzi dello spazio di archiviazione BigQuery.
• Replica dei dati. Per ulteriori informazioni su come viene addebitata 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 a principale, puoi anche utilizzare questi slot per scrivere nella replica.

Puoi acquistare lo stesso numero di slot della regione principale o un numero diverso di slot. Se acquisti meno slot, il rendimento delle query potrebbe essere interessato.

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 posizione della replica aggiunta viene impostata sulla posizione specificata al momento dell'aggiunta. La posizione della replica aggiunta deve essere diversa da quella del set di dati iniziale. Ciò significa che i dati nel set di dati vengono replicati continuamente tra la posizione in cui è stato creato il set di dati e la posizione della replica. Per le repliche che richiedono il co-allocamento, come le visualizzazioni, le visualizzazioni materializzate o le tabelle esterne non BigLake, l'aggiunta di una replica in una posizione diversa da quella dei dati di origine o non compatibile con questa potrebbe causare errori di job.

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

Requisiti per il colocation

L'utilizzo della replica dei set di dati dipende dai seguenti requisiti di co-locazione.

Cloud Storage

L'esecuzione di query sui dati su Cloud Storage richiede che il bucket Cloud Storage sia co-allocato con la replica. Utilizza le considerazioni sulla posizione delle tabelle esterne per decidere dove posizionare la replica.

Limitazioni

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

• I dati negli stream che non sono stati sottoposti a commit non vengono replicati nella replica secondaria se la tabella viene scritta con l'API BigQuery Storage Write. La replica dei dati in streaming dall'API BigQuery Storage Write o da tabledata.insertAll viene eseguita secondo il criterio del massimo impegno e potrebbe verificarsi un ritardo elevato nella replica.
• 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 nella replica secondaria, è necessario prima promuovere la replica secondaria a replica principale.
• Le tabelle iniettate tramite Datastream in BigQuery utilizzando Change Data Capture non sono supportate.
• Non puoi attivare la DML granulare su una tabella in un set di dati replicato e non puoi replicare un set di dati contenente una tabella con la DML granulare abilitata.
• La replica e lo switchover vengono gestiti tramite istruzioni DDL (Data Definition Language) SQL.
• Puoi creare una sola replica di ogni set di dati per ogni regione o per 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 criterio e i criteri relativi ai dati associati non vengono replicati nella replica secondaria. Qualsiasi query che fa riferimento a colonne con tag dei criteri in regioni diverse dalla regione originale non va a buon fine, anche se la replica viene promossa.
• La funzionalità Viaggio nel tempo è disponibile nella replica secondaria solo al termine della sua creazione.
• Puoi replicare solo un set di dati con meno di 100.000 tabelle.
• Puoi aggiungere (e poi eliminare) al massimo 4 repliche nella stessa regione per set di dati al giorno.
• La larghezza di banda è limitata.
• Le tabelle con chiavi di crittografia gestite dal cliente (CMEK) applicate non sono interrogabili nella regione secondaria se il valore replica_kms_key non è configurato.
• Le tabelle BigLake non sono supportate.
• Non puoi replicare set di dati esterni o federati.
• Le località BigQuery Omni non sono supportate.
• Non puoi configurare le seguenti coppie di regioni se stai configurando la replica dei dati per il ripristino di emergenza:
  • us-central1 - us multiregione
  • us-west1 - us multiregione
  • eu-west1 - eu multiregione
  • eu-west4 - eu multiregione

Comportamento delle risorse

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

• Creare un clone di una tabella
• Creare uno snapshot di una tabella

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

Le repliche principali 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 non va a buon fine quando il bucket Cloud Storage non è co-allocato 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 non situata nella stessa posizione della vista logica non vanno a buon fine quando viene eseguita una query.
Tabella gestita	Tabella gestita	Nessuna differenza.
Visualizzazione materializzata	Visualizzazione materializzata	Se una tabella a cui viene fatto riferimento non si trova nella stessa regione della vista materializzata, la query non va a buon fine. Le viste materializzate replicate potrebbero mostrare un'inattività superiore all'inattività massima della vista.
Modello	Modello	Memorizzati come tabelle gestite.
Funzione remota	Funzione remota	Le connessioni sono regionali. Le funzioni remote che fanno riferimento a un set di dati o a una risorsa (connessione) che non si trova nella stessa posizione della funzione remota non vanno a buon fine quando vengono eseguite.
Routine	Funzione definita dall'utente (UDF) o stored procedure	Le routine che fanno riferimento a un set di dati o a una risorsa che non si trova nella stessa posizione della routine non vanno a buon fine quando vengono eseguite. Qualsiasi routine che fa riferimento a una connessione, ad esempio le funzioni remote, non funziona al di fuori della regione di origine.
Criterio di accesso riga	Criterio di accesso riga	Nessuna differenza.
Indice della Ricerca	Indice della Ricerca	Non replicato.
Stored procedure	Stored procedure	Le stored procedure che fanno riferimento a un set di dati o a una risorsa non situata nella stessa posizione della stored procedure non vanno a buon fine quando vengono eseguite.
Clona tabella	Tabella gestita	Fatturato come copia approfondita nella replica secondaria.
Snapshot tabella	Snapshot tabella	Fatturato come copia approfondita nella replica secondaria.
Funzione con valore di tabella (TVF)	TVF	Le funzioni TVF che fanno riferimento a un set di dati o a una risorsa non situata nella stessa posizione della funzione TVF non vanno a buon fine quando vengono eseguite.
Funzioni definite dall'utente	Funzioni definite dall'utente	Le funzioni UDF che fanno riferimento a un set di dati o a una risorsa non situata nella stessa posizione della funzione UDF non vanno a buon fine durante l'esecuzione.

Scenari di interruzione del servizio

La replica tra regioni non è pensata per essere utilizzata come piano di ripristino di emergenza durante un'interruzione totale della regione. In caso di interruzione totale della 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. Per saperne di più sulla preparazione al ripristino di emergenza, consulta Disaster recovery gestito.

La tabella seguente spiega l'impatto delle interruzioni totali della regione sui dati replicati:

Regione 1	Regione 2	Regione in cui si è verificato l'interruzione del servizio	Impatto
Replica principale	Replica secondaria	Regione 2	I job di sola lettura in esecuzione nella regione 2 sulla replica secondaria non vanno a buon fine.
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 in cui si trova la replica secondaria. I contenuti della regione 2 non sono aggiornati finché non viene eseguita la sincronizzazione con la regione 1.

Utilizzare la replica dei set di dati

Questa sezione descrive come replicare un set di dati, promuovere la replica secondaria ed eseguire job di lettura di 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.

Replicare 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 regione o in più regioni che non è già replicato in quella regione o in quelle regioni. Dopo aver aggiunto una replica, è necessario del tempo per completare l'operazione di copia iniziale. 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 di una regione multipla.

Il seguente esempio crea un set di dati denominato my_dataset nella regione 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 confermare che la replica secondaria è stata creata correttamente, puoi eseguire query sulla colonna creation_complete nella visualizzazione INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Promuovi la replica secondaria

Se la regione principale è online, puoi promuovere la replica secondaria. La promozione imposta la replica secondaria come principale scrivibile. Questa operazione viene completata entro pochi secondi se la replica secondaria è aggiornata con la replica principale. Se la replica secondaria non è aggiornata, la promozione non può essere completata finché non lo sarà. La replica secondaria non può essere promossa a principale se nella regione contenente l'istanza principale si verifica un'interruzione.

Tieni presente quanto segue:

• Tutte le scritture nelle tabelle restituiscono errori durante la promozione. La vecchia replica principale diventa non scrivibile immediatamente all'inizio della promozione.
• Le tabelle che non sono completamente replicate al momento dell'avvio della promozione restaurano letture non aggiornate.

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

Tieni presente quanto segue: - Devi impostare esplicitamente la località del job sulla regione secondaria nelle impostazioni della query. Consulta Specificare le località in BigQuery.

Nell'esempio seguente la replica us-east4 viene promossa a principale:

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

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

Rimuovere 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`;

Per eliminare l'intero set di dati, devi prima eliminare eventuali repliche secondarie. Se elimini l'intero set di dati, ad esempio utilizzando l'istruzione DROP SCHEMA, senza eliminare tutte le repliche secondarie, viene visualizzato un errore.

Elenca le repliche del set di dati

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

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 all'altra. L'esempio seguente mostra la procedura di migrazione del set di dati my_migration esistente dalla regione multipla US alla regione multipla EU utilizzando la replica tra regioni.

Replica il set di dati

Per iniziare la procedura di migrazione, replica prima il set di dati nella regione in cui vuoi eseguire la migrazione dei dati. In questo scenario, esegui la migrazione del set di dati my_migration nella regione multipla 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 regione multipla EU. La replica principale è il set di dati my_migration nella regione multipla US.

Promuovi la replica secondaria

Per continuare la migrazione del set di dati alla regione multipla EU, promuovi la replica secondaria:

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

Al termine della promozione, eu è la replica principale. Si tratta di una replica scrivibile.

Completare la migrazione

Per completare la migrazione dal multiregione US al multiregione EU, elimina la replica us. Questo passaggio non è obbligatorio, ma è utile se non hai bisogno di una replica del set di dati oltre le tue esigenze di migrazione.

ALTER SCHEMA my_migration
DROP REPLICA IF EXISTS us;

Il tuo set di dati si trova nella regione multipla EU e non sono presenti repliche del set di dati my_migration. Hai eseguito la migrazione del set di dati alla regione più.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 nel set di dati replicato, devi impostare replica_kms_key per la posizione 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 default_kms_key, devi fornire un 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 puoi impostare replica_kms_key.

• Se utilizzi la rotazione delle chiavi Cloud KMS su uno (o su entrambi) dei default_kms_key o del replica_kms_key, il set di dati replicato è ancora interrogabile dopo la rotazione della chiave.

  • La rotazione delle chiavi nella regione principale aggiorna la versione della chiave solo nelle tabelle create dopo la rotazione, mentre le tabelle esistenti prima della rotazione della chiave continuano a utilizzare la versione della chiave impostata prima della rotazione.
  • La rotazione delle chiavi nella regione secondaria aggiorna tutte le tabelle nella replica secondaria alla nuova versione della chiave.
  • Il passaggio dalla replica principale alla replica secondaria aggiorna tutte le tabelle della replica secondaria (in precedenza la replica principale) alla nuova versione della chiave.
  • Se la versione della chiave impostata sulle tabelle nella replica principale prima della rotazione della chiave viene eliminata, non è possibile eseguire query su nessuna tabella che utilizza ancora la versione della chiave impostata prima della rotazione della chiave finché la versione della chiave non viene aggiornata. Per aggiornare la versione della chiave, la versione precedente deve essere attiva (non disabilitata o eliminata).

• Se nel set di dati di origine non è impostato un valore per default_kms_key, ma nel set di dati di origine sono presenti singole tabelle con CMEK applicato, queste tabelle non sono interrogabili 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.

Creare 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 all'account di servizio BigQuery l'autorizzazione per la crittografia e la decrittografia.

-- 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');

Limiti di CMEK

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

• Non puoi aggiornare la chiave Cloud KMS replicata dopo la sua creazione.

• Non puoi aggiornare il valore default_kms_key nel 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.

Passaggi successivi

• Scopri come utilizzare le prenotazioni BigQuery.
• Scopri di più sulle funzionalità di affidabilità di BigQuery.