Utilizzare la replica tra regioni e ripristino di emergenza

Borderless Lakehouse supporta la replica tra regioni e il disaster recovery per i metadati del catalogo.

Questa configurazione richiede cataloghi supportati da bucket Cloud Storage a due regioni o multiregionali.

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 hai già questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore Service Usage (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 di runtime Lakehouse, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Eseguire attività amministrative, come la gestione dell'accesso degli utenti al catalogo, l'accesso allo spazio di archiviazione e la modalità di distribuzione delle credenziali del catalogo:
  • Lettura dei dati della tabella in modalità di distribuzione delle credenziali: BigLake Viewer (roles/biglake.viewer) sul progetto
  • Scrivere i dati della tabella in modalità di distribuzione delle credenziali: BigLake Editor (roles/biglake.editor) sul progetto
  • Leggi le risorse del catalogo e i dati delle tabelle in modalità di distribuzione non delle credenziali:
  • Gestisci le risorse del catalogo e scrivi i dati della tabella in modalità di distribuzione non 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 principale e secondaria per assicurarti che siano pronte per una transizione.
  3. Scegli una modalità di failover: Decidi tra un faiover soft (ideale per la manutenzione programmata) o un faiover hard (ideale per il ripristino di emergenza).
  4. Avvia il failover: esegui il comando corrispondente alla modalità scelta per cambiare le regioni principale e secondaria.

Preparati al failover

Identifica la tua regione principale attuale e verifica lo stato di sincronizzazione della regione secondaria. Quindi, avvia il failover.

Visualizza lo stato della replica

Per determinare le regioni in cui viene replicato il catalogo, esegui il seguente comando gcloud biglake iceberg catalogs describe.

gcloud biglake iceberg catalogs describe CATALOG_NAME

Sostituisci CATALOG_NAME con il nome del tuo catalogo.

Controlla 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 principale.

Avvia un failover

La funzionalità di ripristino di emergenza utilizza la replica del metastore per designare le regioni primarie e secondarie. Tutti i metadati di commit della tabella vengono forniti dalla regione principale e replicati nella regione secondaria. Puoi cambiare le regioni principale e secondaria del catalogo utilizzando l'operazione di failover.

Failover graduale

Per avviare un failover soft, 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 principale.

Failover forzato

Per avviare un failover completo, 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 principale.
  • 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 quel 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 eventuali ritardi di replica, imposta questo timestamp su una data molto precedente. Nota: mentre questa funzionalità è in anteprima, REPLICATION_TIMESTAMP tiene traccia solo dei metadati del catalogo, non dei file di Cloud Storage. Per mantenere la perdita di dati con un limite inferiore, consulta la documentazione sulla disponibilità e durabilità dei dati di Cloud Storage.

Passaggi successivi