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 de Cloud Storage de doble región o multirregión.
Antes de comenzar
-
Verifica que la facturación esté habilitada para tu Google Cloud proyecto.
-
Habilita la API de BigLake.
Roles necesarios para habilitar las APIs
Para habilitar las APIs, necesitas el permiso
serviceusage.services.enable. Si creaste el proyecto, es probable que ya tengas este permiso a través del rol de propietario (roles/owner). De lo contrario, puedes obtener este permiso a través del rol de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin). Obtén información para otorgar roles.
Roles obligatorios
Para obtener los permisos que necesitas para usar el extremo del catálogo REST de Iceberg en el catálogo de entornos de ejecución de Lakehouse, pídele a tu administrador que te otorgue los siguientes roles de IAM:
-
Realiza 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 (
-
Lee datos de la tabla en el modo de venta de credenciales:
Visualizador de BigLake (
roles/biglake.viewer) en el proyecto -
Escribe datos de la tabla en el modo de venta de credenciales:
Editor de BigLake (
roles/biglake.editor) en el proyecto -
Lee recursos del catálogo y datos de la tabla en el modo de venta de credenciales:
- Visualizador de BigLake (
roles/biglake.viewer) en el proyecto - Visualizador de objetos de almacenamiento (
roles/storage.objectViewer) en el bucket de Cloud Storage
- Visualizador de BigLake (
-
Administra recursos del catálogo y escribe datos de la tabla en el modo de 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 mediante 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:
- Visualiza el estado de la replicación: Identifica tus regiones principal y secundaria actuales para determinar la región de destino para 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 manual (ideal para el mantenimiento planificado) o una conmutación por error forzada (ideal para la recuperación de emergencia).
- Inicia la conmutación por error: Ejecuta el comando correspondiente al modo elegido para cambiar tus regiones principal y secundaria.
Prepárate 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.
Visualiza el estado de la replicación
Para determinar las regiones en las que se replica tu catálogo, ejecuta el siguiente
gcloud biglake iceberg catalogs describe comando.
gcloud biglake iceberg catalogs describe CATALOG_NAME
Reemplaza CATALOG_NAME por el nombre de tu catálogo.
Verifica 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 gcloud biglake iceberg catalogs failover
comando:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--validate_only \
--primary-replica PRIMARY_REPLICA_REGION
Reemplaza lo siguiente:
CATALOG_NAME: el nombre de tu catálogo.PRIMARY_REPLICA_REGION: 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 de metastore para designar regiones principal y secundaria. 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 manual, ejecuta el siguiente gcloud biglake iceberg catalogs failover
comando:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION
Reemplaza lo siguiente:
CATALOG_NAME: el nombre de tu catálogo.PRIMARY_REPLICA_REGION: 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 gcloud biglake iceberg catalogs failover
comando:
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION \
--conditional-failover-replication-time=REPLICATION_TIMESTAMP
Reemplaza lo siguiente:
CATALOG_NAME: el nombre de tu catálogo.PRIMARY_REPLICA_REGION: la región que se designará como la nueva réplica principal.REPLICATION_TIMESTAMP: una marca de tiempo RFC 3339 que actúa como un 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 falla. Para forzar el proceso de conmutación por error, independientemente de cualquier demora de replicación, establece esta marca de tiempo en una fecha muy anterior. Nota: Mientras esta función esté en versión preliminar, el REPLICATION_TIMESTAMP solo hará un seguimiento de los metadatos del catálogo, en lugar de los archivos de Cloud Storage. Para mantener la pérdida de datos con un límite inferior, consulta la documentación Disponibilidad y durabilidad de los datos de Cloud Storage.