Lakehouse para Apache Iceberg admite la replicación entre regiones y la recuperación ante desastres para los metadatos del catálogo.
Esta configuración requiere catálogos respaldados por buckets birregionales o multirregionales de Cloud Storage.
Antes de comenzar
-
Verifica que la facturación esté habilitada para tu proyecto de Google Cloud .
-
Habilita la API de BigLake.
Roles necesarios para habilitar las APIs
Para habilitar las APIs, necesitas el rol de IAM de administrador de Service Usage (
roles/serviceusage.serviceUsageAdmin), que contiene el permisoserviceusage.services.enable. Obtén más información para otorgar roles.
Roles obligatorios
Para obtener los permisos que necesitas para usar el extremo del catálogo de Iceberg REST en el catálogo del entorno de ejecución de Lakehouse, pídele a tu administrador que te otorgue los siguientes roles de IAM:
-
Realizar tareas administrativas, como administrar el acceso de los usuarios al catálogo, el acceso al almacenamiento y el modo de venta de credenciales del catálogo:
- Administrador de BigLake (
roles/biglake.admin) en el proyecto - Administrador de almacenamiento (
roles/storage.admin) en el bucket de Cloud Storage
- Administrador de BigLake (
-
Leer datos de la tabla en el modo de venta de credenciales:
Visualizador de BigLake (
roles/biglake.viewer) en el proyecto -
Escribir datos de la tabla en el modo de venta de credenciales:
Editor de BigLake (
roles/biglake.editor) en el proyecto -
Leer recursos del catálogo y datos de tablas en el modo de no venta de credenciales:
- Visualizador de BigLake (
roles/biglake.viewer) en el proyecto - Visualizador de objetos de Storage (
roles/storage.objectViewer) en el bucket de Cloud Storage
- Visualizador de BigLake (
-
Administra los recursos del catálogo y escribe datos de la tabla en el modo de no venta de credenciales:
- Editor de BigLake (
roles/biglake.editor) en el proyecto - Usuario de objetos de almacenamiento (
roles/storage.objectUser) en el bucket de Cloud Storage
- Editor de BigLake (
Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.
También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.
Flujo de trabajo de replicación y recuperación ante desastres
Para usar la replicación entre regiones y la recuperación ante desastres, sigue estos pasos generales:
- Consulta el estado de la replicación: Identifica tus regiones principal y secundaria actuales para determinar la región de destino de la conmutación por error.
- Verifica el estado de sincronización: Verifica el estado actual de tus regiones principal y secundaria para asegurarte de que estén listas para una transición.
- Elige un modo de conmutación por error: Decide entre una conmutación por error parcial (ideal para el mantenimiento planificado) o una conmutación por error total (ideal para la recuperación ante emergencias).
- Inicia la conmutación por error: Ejecuta el comando correspondiente al modo que elegiste para cambiar las regiones principal y secundaria.
Preparación para la conmutación por error
Identifica tu región principal actual y verifica el estado de sincronización de tu región secundaria. Luego, inicia la conmutación por error.
Cómo ver el estado de la replicación
Para determinar las regiones en las que se replica tu catálogo, ejecuta el siguiente comando de gcloud biglake iceberg catalogs describe.
gcloud biglake iceberg catalogs describe CATALOG_NAME
Reemplaza CATALOG_NAME por el nombre de tu catálogo.
Cómo verificar el estado de sincronización
Antes de iniciar una conmutación por error, verifica el estado de sincronización de tu réplica secundaria con el comando gcloud biglake iceberg catalogs failover:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--validate_only \
--primary-replica PRIMARY_REPLICA_REGION
Reemplaza lo siguiente:
CATALOG_NAME: Es el nombre de tu catálogo.PRIMARY_REPLICA_REGION: Es la región que se designará como la nueva réplica principal.
Inicia una conmutación por error
La función de recuperación ante desastres usa la replicación del metastore para designar regiones principales y secundarias. Todos los metadatos de confirmación de la tabla se entregan desde la región principal y se replican en la región secundaria. Puedes cambiar las regiones principal y secundaria del catálogo con la operación de conmutación por error.
Conmutación por error manual
Para iniciar una conmutación por error parcial, ejecuta el siguiente comando gcloud biglake iceberg catalogs failover:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION
Reemplaza lo siguiente:
CATALOG_NAME: Es el nombre de tu catálogo.PRIMARY_REPLICA_REGION: Es la región que se designará como la nueva réplica principal.
Conmutación por error forzada
Para iniciar una conmutación por error forzada, ejecuta el siguiente comando gcloud biglake iceberg catalogs failover:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION \
--conditional-failover-replication-time=REPLICATION_TIMESTAMP
Reemplaza lo siguiente:
CATALOG_NAME: Es el nombre de tu catálogo.PRIMARY_REPLICA_REGION: Es la región que se designará como la nueva réplica principal.REPLICATION_TIMESTAMP: Es una marca de tiempo RFC 3339 que actúa como punto de control para la replicación. El proceso de replicación verifica que la réplica contenga todos los datos confirmados hasta este momento. Si la réplica no contiene todos los datos confirmados antes de esta marca de tiempo, el comando fallará. Para forzar el proceso de conmutación por error independientemente de cualquier demora en la replicación, establece esta marca de tiempo en una fecha muy anterior. Nota: Mientras esta función esté en versión preliminar, REPLICATION_TIMESTAMP solo hará un seguimiento de los metadatos del catálogo, no de los archivos de Cloud Storage. Para mantener la pérdida de datos con un límite inferior, consulta la documentación de Disponibilidad y durabilidad de los datos de Cloud Storage.