Utiliser la réplication et la reprise après sinistre interrégionales

Lakehouse pour Apache Iceberg est compatible avec la réplication interrégionale et la reprise après sinistre pour les métadonnées de catalogue.

Cette configuration nécessite des catalogues soutenus par des buckets Cloud Storage birégionaux ou multirégionaux.

Avant de commencer

  1. Vérifiez que la facturation est activée pour votre projet Google Cloud .

  2. Activez l'API BigLake.

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles.

    Activer l'API

Rôles requis

Pour obtenir les autorisations nécessaires pour utiliser le point de terminaison du catalogue REST Iceberg dans le catalogue du runtime Lakehouse, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • Effectuer des tâches administratives, comme gérer l'accès des utilisateurs au catalogue et au stockage, ainsi que le mode de distribution des identifiants du catalogue :
  • Lire les données de table en mode distribution d'identifiants : Lecteur BigLake (roles/biglake.viewer) sur le projet
  • Écrire des données de table en mode distribution d'identifiants : Éditeur BigLake (roles/biglake.editor) sur le projet
  • Lire les ressources de catalogue et les données de table en mode sans distribution d'identifiants :
  • Gérer les ressources du catalogue et écrire des données de table en mode sans distribution d'identifiants :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Workflow de réplication et de reprise après sinistre

Pour utiliser la réplication et la reprise après sinistre interrégionales, procédez comme suit :

  1. Afficher l'état de la réplication : identifiez vos régions principale et secondaire actuelles pour déterminer la région cible du basculement.
  2. Vérifiez l'état de la synchronisation : vérifiez l'état actuel de vos régions principale et secondaire pour vous assurer qu'elles sont prêtes pour une transition.
  3. Choisissez un mode de basculement : optez pour un basculement progressif (idéal pour la maintenance planifiée) ou un basculement forcé (idéal pour la reprise d'urgence).
  4. Lancez le basculement : exécutez la commande correspondant au mode choisi pour inverser vos régions principale et secondaire.

Préparer le basculement

Identifiez votre région principale actuelle et vérifiez l'état de synchronisation de votre région secondaire. Ensuite, lancez le basculement.

Afficher l'état de la réplication

Pour déterminer les régions dans lesquelles votre catalogue est répliqué, exécutez la commande gcloud biglake iceberg catalogs describe suivante.

gcloud biglake iceberg catalogs describe CATALOG_NAME

Remplacez CATALOG_NAME par le nom de votre catalogue.

Vérifier l'état de la synchronisation

Avant d'initier un basculement, vérifiez l'état de synchronisation de votre réplica secondaire avec la commande gcloud biglake iceberg catalogs failover :

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --validate_only \
    --primary-replica PRIMARY_REPLICA_REGION

Remplacez les éléments suivants :

  • CATALOG_NAME : nom de votre catalogue.
  • PRIMARY_REPLICA_REGION : région à désigner comme nouvelle réplique principale.

Initier un basculement

La fonctionnalité de reprise après sinistre utilise la réplication du metastore pour désigner les régions principales et secondaires. Toutes les métadonnées de validation des tables sont diffusées à partir de la région principale et répliquées dans la région secondaire. Vous pouvez échanger les régions principale et secondaire du catalogue à l'aide de l'opération de basculement.

Basculement progressif

Pour lancer un basculement progressif, exécutez la commande gcloud biglake iceberg catalogs failover suivante :

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION

Remplacez les éléments suivants :

  • CATALOG_NAME : nom de votre catalogue.
  • PRIMARY_REPLICA_REGION : région à désigner comme nouvelle réplique principale.

Basculement forcé

Pour lancer un basculement forcé, exécutez la commande gcloud biglake iceberg catalogs failover suivante :

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION \
    --conditional-failover-replication-time=REPLICATION_TIMESTAMP

Remplacez les éléments suivants :

  • CATALOG_NAME : nom de votre catalogue.
  • PRIMARY_REPLICA_REGION : région à désigner comme nouvelle instance répliquée principale.
  • REPLICATION_TIMESTAMP : code temporel RFC 3339 servant de point de contrôle pour la réplication. Le processus de réplication vérifie que l'instance dupliquée contient toutes les données validées jusqu'à ce moment. Si la réplique ne contient pas toutes les données validées avant ce code temporel, la commande échoue. Pour forcer le processus de basculement, quel que soit le délai de réplication, définissez ce code temporel sur une date très ancienne. Remarque : Tant que cette fonctionnalité est en version Preview, REPLICATION_TIMESTAMP ne suit que les métadonnées du catalogue, et non les fichiers Cloud Storage. Pour limiter la perte de données, consultez la documentation Cloud Storage sur la disponibilité et la durabilité des données.

Étapes suivantes