Lakehouse for Apache Iceberg supporta la replica tra regioni e il ripristino di emergenza per i metadati del catalogo.
Questa configurazione richiede cataloghi supportati da bucket Cloud Storage a doppia regione o a più regioni.
Prima di iniziare
-
Verifica che la fatturazione sia attivata per il tuo Google Cloud progetto.
-
Abilita l'API BigLake.
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo servizi (
roles/serviceusage.serviceUsageAdmin), che contiene l'autorizzazioneserviceusage.services.enable. Scopri come concedere i ruoli.
Ruoli obbligatori
Per ottenere le autorizzazioni necessarie per utilizzare l'endpoint del catalogo REST Iceberg nel catalogo runtime Lakehouse, chiedi all'amministratore di concederti i seguenti ruoli IAM:
-
Eseguire attività amministrative, come la gestione dell'accesso utente al catalogo, l'accesso allo spazio di archiviazione e la modalità di distribuzione delle credenziali del catalogo:
- BigLake Admin (
roles/biglake.admin) sul progetto - Storage Admin (
roles/storage.admin) sul bucket Cloud Storage
- BigLake Admin (
-
Leggere i dati delle tabelle in modalità di distribuzione delle credenziali:
BigLake Viewer (
roles/biglake.viewer) sul progetto -
Scrivere i dati delle tabelle in modalità di distribuzione delle credenziali:
BigLake Editor (
roles/biglake.editor) sul progetto -
Leggere le risorse del catalogo e i dati delle tabelle in modalità di distribuzione delle credenziali:
- BigLake Viewer (
roles/biglake.viewer) sul progetto - Storage Object Viewer (
roles/storage.objectViewer) sul bucket Cloud Storage
- BigLake Viewer (
-
Gestire le risorse del catalogo e scrivere i dati delle tabelle in modalità di distribuzione delle credenziali:
- BigLake Editor (
roles/biglake.editor) sul progetto - Storage Object User (
roles/storage.objectUser) sul bucket Cloud Storage
- BigLake Editor (
Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.
Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.
Flusso di lavoro di replica e ripristino di emergenza
Per utilizzare la replica tra regioni e il ripristino di emergenza, segui questi passaggi generali:
- Visualizza lo stato della replica: identifica le regioni primaria e secondaria attuali per determinare la regione di destinazione per il failover.
- Controlla lo stato della sincronizzazione: verifica lo stato attuale delle regioni primaria e secondaria per assicurarti che siano pronte per una transizione.
- Scegli una modalità di failover: scegli tra un failover graduale (ideale per la manutenzione pianificata) o un failover forzato (ideale per il ripristino di emergenza ).
- Avvia il failover: esegui il comando corrispondente alla modalità scelta per cambiare le regioni primaria e secondaria.
Prepararsi per il failover
Identifica la regione primaria attuale e verifica lo stato di sincronizzazione della regione secondaria. Quindi, avvia il failover.
Visualizzare lo stato della replica
Per determinare le regioni in cui viene replicato il catalogo, esegui il seguente
gcloud biglake iceberg catalogs describe comando.
gcloud biglake iceberg catalogs describe CATALOG_NAME
Sostituisci CATALOG_NAME con il nome del catalogo.
Controllare lo stato della sincronizzazione
Prima di avviare un failover, controlla lo stato di sincronizzazione della tua
replica secondaria con il gcloud biglake iceberg catalogs failover
comando:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--validate_only \
--primary-replica PRIMARY_REPLICA_REGION
Sostituisci quanto segue:
CATALOG_NAME: il nome del catalogo.PRIMARY_REPLICA_REGION: la regione da designare come nuova replica primaria.
Avviare un failover
La funzionalità di ripristino di emergenza utilizza la replica del metastore per designare le regioni primaria e secondaria. Tutti i metadati di commit delle tabelle vengono forniti dalla regione primaria e replicati nella regione secondaria. Puoi cambiare le regioni primaria e secondaria per il catalogo utilizzando l'operazione di failover.
Failover graduale
Per avviare un failover graduale, esegui il seguente gcloud biglake iceberg catalogs failover
comando:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION
Sostituisci quanto segue:
CATALOG_NAME: il nome del catalogo.PRIMARY_REPLICA_REGION: la regione da designare come nuova replica primaria.
Failover forzato
Per avviare un failover forzato, esegui il seguente gcloud biglake iceberg catalogs failover
comando:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION \
--conditional-failover-replication-time=REPLICATION_TIMESTAMP
Sostituisci quanto segue:
CATALOG_NAME: il nome del catalogo.PRIMARY_REPLICA_REGION: la regione da designare come nuova replica primaria.REPLICATION_TIMESTAMP: un timestamp RFC 3339 che funge da checkpoint per la replica. Il processo di replica verifica che la replica contenga tutti i dati di cui è stato eseguito il commit fino a questo momento. Se la replica non contiene tutti i dati di cui è stato eseguito il commit prima di questo timestamp, il comando non riesce. Per forzare il processo di failover indipendentemente da eventuali ritardi di replica, imposta questo timestamp su una data molto precedente. Nota: mentre questa funzionalità è in anteprima, il REPLICATION_TIMESTAMP tiene traccia solo dei metadati del catalogo, anziché dei file di Cloud Storage. Per mantenere la perdita di dati con un limite inferiore, consulta la documentazione Disponibilità e durabilità dei dati di Cloud Storage.