Utilizzare la replica tra regioni e ripristino di emergenza

Borderless Lakehouse supporta la replica tra regioni e il ripristino di emergenza per i metadati del catalogo.

Questa configurazione richiede cataloghi supportati da bucket dual-region o multiregionali di Cloud Storage.

Prima di iniziare

  1. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud .

  2. Abilita l'API BigLake, se non è già abilitata.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente disponi già di questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli.

    Abilitare l'API

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per utilizzare l'endpoint del catalogo REST Iceberg nel catalogo del runtime Lakehouse, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Eseguire attività amministrative, come la gestione dell'accesso utente al catalogo, dell'accesso allo spazio di archiviazione e della modalità di distribuzione delle credenziali del catalogo:
  • Leggi i dati della tabella in modalità di distribuzione delle credenziali: Visualizzatore BigLake (roles/biglake.viewer) sul progetto
  • Scrivi i dati della tabella in modalità di distribuzione delle credenziali: Editor BigLake (roles/biglake.editor) sul progetto
  • Leggi le risorse del catalogo e i dati delle tabelle in modalità non di distribuzione delle credenziali:
  • Gestisci le risorse del catalogo e scrivi i dati delle tabelle in modalità non di distribuzione delle credenziali:

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.

Workflow di replica e ripristino di emergenza

Per utilizzare la replica tra regioni e il ripristino di emergenza, segui questi passaggi generali:

  1. Visualizza lo stato della replica:identifica le regioni principali e secondarie attuali per determinare la regione di destinazione per il failover.
  2. Controlla lo stato della sincronizzazione: verifica lo stato attuale delle regioni primaria e secondaria per assicurarti che siano pronte per una transizione.
  3. Scegli una modalità di failover:decidi tra un soft failover (ideale per la manutenzione pianificata) o un hard failover (ideale per il ripristino di emergenza).
  4. Avvia il failover:esegui il comando corrispondente alla modalità scelta per scambiare le regioni principale e secondaria.

Prepararsi al failover

Identifica la tua regione principale 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 questo comando gcloud biglake iceberg catalogs describe.

gcloud biglake iceberg catalogs describe CATALOG_NAME

Sostituisci CATALOG_NAME con il nome del tuo catalogo.

Controllare lo stato della sincronizzazione

Prima di avviare un failover, controlla lo stato di sincronizzazione della replica secondaria con il comando gcloud biglake iceberg catalogs failover:

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.

Avvia 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 della tabella vengono pubblicati dalla regione primaria e replicati nella regione secondaria. Puoi scambiare le regioni principale e secondaria per il catalogo utilizzando l'operazione di failover.

Failover graduale

Per avviare un failover controllato, esegui questo comando gcloud biglake iceberg catalogs failover:

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 questo comando gcloud biglake iceberg catalogs failover:

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 va a buon fine. Per forzare il processo di failover indipendentemente da qualsiasi ritardo di replica, imposta questo timestamp su una data molto precedente. Nota: mentre questa funzionalità è in anteprima, REPLICATION_TIMESTAMP monitora solo i metadati del catalogo, anziché i file Cloud Storage. Per mantenere la perdita di dati con un limite inferiore, consulta la documentazione di Cloud Storage Disponibilità e durabilità dei dati.

Passaggi successivi