Lakehouse for Apache Iceberg prend en charge la réplication interrégionale et la reprise après sinistre pour les métadonnées du catalogue.
Cette configuration nécessite des catalogues sauvegardés par des buckets Cloud Storage birégionaux ou multirégionaux.
Avant de commencer
-
Vérifiez que la facturation est activée pour votre Google Cloud projet.
-
Activez l'API BigLake.
Rôles requis pour activer les API
Pour activer les API, vous devez disposer de l'autorisation
serviceusage.services.enable. Si vous avez créé le projet, vous disposez probablement déjà de cette autorisation via le rôle Propriétaire (roles/owner). Sinon, vous pouvez l'obtenir via le rôle Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin). Découvrez comment attribuer des rôles.
Rôles requis
Pour obtenir les autorisations nécessaires pour utiliser le point de terminaison du catalogue REST Iceberg dans le catalogue d'environnements d'exécution Lakehouse, demandez à votre administrateur de vous accorder les rôles IAM suivants :
-
Effectuer des tâches administratives, telles que la gestion de l'accès des utilisateurs au catalogue, de l'accès au stockage et du mode de distribution des identifiants du catalogue :
- Administrateur BigLake (
roles/biglake.admin) sur le projet - Administrateur de l'espace de stockage (
roles/storage.admin) sur le bucket Cloud Storage
- Administrateur BigLake (
-
Lire les données de la table en mode de distribution des identifiants :
Lecteur BigLake (
roles/biglake.viewer) sur le projet -
Écrire les données de la table en mode de distribution des identifiants :
Éditeur BigLake (
roles/biglake.editor) sur le projet -
Lire les ressources du catalogue et les données de la table en mode de non-distribution des identifiants :
- Lecteur BigLake (
roles/biglake.viewer) sur le projet - Lecteur des objets Storage (
roles/storage.objectViewer) sur le bucket Cloud Storage
- Lecteur BigLake (
-
Gérer les ressources du catalogue et écrire les données de la table en mode de non-distribution des identifiants :
- Éditeur BigLake (
roles/biglake.editor) sur le projet - Utilisateur d'objets Storage (
roles/storage.objectUser) sur le bucket Cloud Storage
- Éditeur BigLake (
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 via 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 interrégionale et la reprise après sinistre, procédez comme suit :
- Afficher l'état de la réplication : identifiez vos régions principale et secondaire actuelles pour déterminer la région cible du basculement.
- Vérifier 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.
- Choisir un mode de basculement : choisissez entre un basculement progressif (idéal pour la maintenance planifiée) ou un basculement forcé (idéal pour la reprise d'urgence ).
- Lancer le basculement : exécutez la commande correspondant au mode choisi pour permuter 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. Lancez ensuite 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 suivante
gcloud biglake iceberg catalogs describe.
gcloud biglake iceberg catalogs describe CATALOG_NAME
Remplacez CATALOG_NAME par le nom de votre catalogue.
Vérifier l'état de la synchronisation
Avant de lancer un basculement, vérifiez l'état de synchronisation de votre
instance dupliquée secondaire à l'aide de la gcloud biglake iceberg catalogs failover
commande :
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 instance dupliquée principale.
Lancer un basculement
La fonctionnalité de reprise après sinistre utilise la réplication du metastore pour désigner les régions principale et secondaire. Toutes les métadonnées de commit de la table sont diffusées à partir de la région principale et répliquées dans la région secondaire. Vous pouvez permuter 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 gcloud biglake iceberg catalogs failover
commande 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 instance dupliquée principale.
Basculement forcé
Pour lancer un basculement forcé, exécutez la gcloud biglake iceberg catalogs failover
commande 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 dupliquée principale.REPLICATION_TIMESTAMP: code temporel RFC 3339 qui sert 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 l'instance dupliquée 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 : Lorsque cette fonctionnalité est en version Preview, le 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 Disponibilité et durabilité des données Cloud Storage.