Migrar a la recuperación tras fallos gestionada

En esta página se describe cómo migrar de la replicación entre regiones de BigQuery a la recuperación tras fallos gestionada de BigQuery.

Información general

La replicación entre regiones (CRR) y la recuperación tras fallos (DR) gestionada de BigQuery son dos funciones diseñadas para mejorar la disponibilidad de los datos y las funciones de recuperación tras fallos. Sin embargo, gestionan los cortes regionales de forma diferente. CRR no permite promocionar la réplica secundaria si la región principal no está disponible. Por el contrario, la recuperación tras desastres ofrece una protección más completa, ya que permite conmutar por error a la réplica secundaria aunque la región principal no esté disponible. Con CRR, solo se replica el almacenamiento, mientras que con DR se replican tanto el almacenamiento como la capacidad de computación.

En la siguiente tabla se describen las funciones de la replicación entre regiones y la recuperación ante desastres:

Función CRR DR
Proceso de replicación inicial Usa CRR para replicar el conjunto de datos inicialmente. La carga inicial se replica previamente con CRR antes de migrar un conjunto de datos de CRR a un conjunto de datos de recuperación ante desastres.
Replicación de promociones Usa la replicación estándar. Usa la replicación turbo.
Proceso de promoción Promueve a nivel del conjunto de datos. Promueve a nivel de reserva (conmutación por error de la reserva y promoción del conjunto de datos). Se pueden adjuntar muchos conjuntos de datos a una reserva de conmutación por error. La promoción a nivel de conjunto de datos no está disponible con DR.
Ejecución de promociones Mediante la interfaz de usuario o un comando DDL basado en SQL para cada conjunto de datos. No se ofrece asistencia para la CLI, las bibliotecas de cliente, la API ni Terraform. Mediante la interfaz de usuario o un comando DDL basado en SQL para cada reserva de EPE. No se admite la CLI, las bibliotecas de cliente, la API ni Terraform.
Modo de conmutación por error Conmutación por error suave. Conmutación por error forzada.
Requisito de edición Cualquier modelo de capacidad. Edición Enterprise Plus.
Limitaciones Limitaciones de la CRR. Incluye las limitaciones de CRR y las limitaciones de DR.
Acceso de escritura Los trabajos que se ejecutan con cualquier modelo de capacidad pueden escribir en conjuntos de datos replicados en la región principal. La secundaria es siempre de solo lectura. Solo los trabajos que se ejecutan en reservas de Enterprise Plus pueden escribir en conjuntos de datos replicados en la región principal. Las réplicas de conjuntos de datos y de reservas secundarios siempre son de solo lectura.
Acceso de lectura Los trabajos que se ejecutan con cualquier modelo de capacidad pueden leer datos de conjuntos de datos replicados. Los trabajos que se ejecutan con cualquier modelo de capacidad pueden leer datos de conjuntos de datos replicados.

Implicaciones de la migración

En las siguientes secciones se ofrece un resumen de los cambios en los costes y las funciones que se producen al migrar a la recuperación ante desastres.

Implicaciones económicas

Ten en cuenta las siguientes implicaciones de costes al migrar de CRR a DR:

  • La recuperación ante desastres solo admite el acceso de escritura desde la edición Enterprise Plus, lo que conlleva costes de computación más elevados. Puedes leer desde cualquier modelo de capacidad, por lo que los costes de lectura de los trabajos actuales no cambian.

  • La recuperación ante desastres usa la replicación Turbo, que conlleva costes adicionales en función del par de regiones.

  • Los precios del almacenamiento son los mismos para la replicación entre regiones y la recuperación ante desastres.

Para obtener más información sobre los precios, consulta la página Precios.

Implicaciones de las funciones

Ten en cuenta las siguientes implicaciones de las funciones al migrar de CRR a DR:

  • La recuperación ante desastres solo admite la conmutación por error a nivel de reserva. Se producirá un error en los trabajos que dependan de la conmutación por error a nivel de conjunto de datos.

  • Solo las consultas de la edición Enterprise Plus pueden escribir en el conjunto de datos una vez que se haya adjuntado a la reserva de recuperación ante desastres. Las tareas de escritura que no usen una edición Enterprise Plus para su capacidad de cálculo fallarán.

Antes de empezar

Antes de iniciar la migración, familiarízate con los conceptos de replicación entre regiones y recuperación tras fallos gestionada.

Para migrar a la recuperación ante desastres, debes cumplir los siguientes requisitos previos:

  • Tienes un Google Cloud proyecto activo con BigQuery habilitado.

  • Ha creado y replicado conjuntos de datos con CRR.

  • Los conjuntos de datos tienen las mismas ubicaciones principal y secundaria que quieres usar para la recuperación ante desastres.

  • Tienes los permisos necesarios para trabajar con la recuperación ante desastres. Para obtener más información sobre los permisos, consulta Antes de empezar.

Migrar de CRR a DR

En las siguientes secciones se describe cómo migrar tus conjuntos de datos de CRR a DR. Se da por hecho que ya has configurado tus conjuntos de datos para CRR.

Crear una reserva de conmutación por error

Para habilitar la recuperación tras fallos, debes crear una reserva de conmutación por error en la región principal. Configura tu reserva con la región principal y la secundaria adecuadas. Las regiones principal y secundaria deben coincidir con las regiones de todos los conjuntos de datos de CRR que quieras migrar a recuperación ante desastres. Para crear una reserva de conmutación por error, elige una de las siguientes opciones:

Consola

  1. En la Google Cloud consola, ve a la página BigQuery.

    Ir a BigQuery

  2. En el menú de navegación, haga clic en Gestión de la capacidad y, a continuación, en Crear reserva.

  3. En el campo Nombre de la reserva, introduce un nombre para la reserva.

  4. En la lista Ubicación, selecciona la ubicación.

  5. En la lista Edition (Edición), selecciona Enterprise Plus.

  6. En la lista Selector de tamaño máximo de reserva, selecciona el tamaño máximo de reserva.

  7. Opcional: En el campo Espacios publicitarios de referencia, introduce el número de espacios publicitarios de referencia de la reserva.

    El número de ranuras de escalado automático disponibles se determina restando el valor de Ranuras de referencia del valor de Tamaño máximo de reserva. Por ejemplo, si creas una reserva con 100 espacios de base y un tamaño máximo de reserva de 400, tu reserva tendrá 300 espacios de escalado automático. Para obtener más información sobre los intervalos de referencia, consulta el artículo Usar reservas con intervalos de referencia y de autoescalado.

  8. En la lista Ubicación secundaria, selecciona la ubicación secundaria.

  9. Para inhabilitar la función de compartir espacios inactivos y usar solo la capacidad de espacio especificada, haga clic en el interruptor Ignorar espacios inactivos.

  10. Para desplegar la sección Configuración avanzada, haz clic en la flecha de expansión.

  11. Opcional: Para definir la simultaneidad de trabajos objetivo, activa el interruptor Anular simultaneidad de trabajos objetivo automática y, a continuación, introduce un valor en Simultaneidad de trabajos objetivo. El desglose de los espacios se muestra en la tabla Estimación de costes. En la tabla Resumen de la capacidad se muestra un resumen de la reserva.

  12. Haz clic en Guardar.

La nueva reserva se muestra en la pestaña Reservas de espacios.

SQL

Para crear una reserva, usa la instrucción del lenguaje de definición de datos (DDL) CREATE RESERVATION.

  1. En la Google Cloud consola, ve a la página BigQuery.

    Ir a BigQuery

  2. En el editor de consultas, introduce la siguiente instrucción:

    CREATE RESERVATION
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
OPTIONS (
  slot_capacity = NUMBER_OF_BASELINE_SLOTS,
  edition = ENTERPRISE_PLUS,
  secondary_location = SECONDARY_LOCATION);

    Haz los cambios siguientes:

    • ADMIN_PROJECT_ID: el ID del proyecto de administración que posee el recurso de reserva.
    • LOCATION: la ubicación de la reserva. Si seleccionas una ubicación de BigQuery Omni, la opción de edición se limitará a la edición Enterprise.

    • RESERVATION_NAME: el nombre de la reserva.

      El nombre debe empezar y terminar con una letra minúscula o un número, y solo puede contener letras minúsculas, números y guiones.

    • NUMBER_OF_BASELINE_SLOTS: número de espacios de referencia que se asignarán a la reserva. No puedes definir las opciones slot_capacity y edition en la misma reserva.
    • SECONDARY_LOCATION: la ubicación secundaria de la reserva. En caso de interrupción, los conjuntos de datos asociados a esta reserva se transferirán a esta ubicación.

  3. Haz clic en Ejecutar.

Para obtener más información sobre cómo ejecutar consultas, consulta Ejecutar una consulta interactiva.

Adjuntar el conjunto de datos a la reserva

Una vez que hayas creado la reserva de conmutación por error, adjunta el conjunto de datos o los conjuntos de datos entre regiones a la reserva. De esta forma, se habilita la conmutación por error para todos los conjuntos de datos adjuntos. Para adjuntar el conjunto de datos a la reserva, elige una de las siguientes opciones:

Consola

  1. En la Google Cloud consola, ve a la página BigQuery.

    Ir a BigQuery

  2. En el menú de navegación, haga clic en Gestión de la capacidad y, a continuación, en la pestaña Reservas de espacio.

  3. Haz clic en la reserva a la que quieras adjuntar un conjunto de datos.

  4. Haz clic en la pestaña Recuperación ante desastres.

  5. Haz clic en Añadir conjunto de datos de conmutación por error.

  6. Introduce el nombre del conjunto de datos que quieras asociar a la reserva.

  7. Haz clic en Añadir.

SQL

Para adjuntar un conjunto de datos a una reserva, usa la declaración de DDL ALTER SCHEMA SET OPTIONS.

  1. En la Google Cloud consola, ve a la página BigQuery.

    Ir a BigQuery

  2. En el editor de consultas, introduce la siguiente instrucción:

    ALTER SCHEMA
  `DATASET_NAME`
SET OPTIONS (
  failover_reservation = ADMIN_PROJECT_ID.RESERVATION_NAME);

    Haz los cambios siguientes:

    • DATASET_NAME: el nombre del conjunto de datos.

    • ADMIN_PROJECT_ID.RESERVATION_NAME: el nombre de la reserva a la que quieres asociar el conjunto de datos.

  3. Haz clic en Ejecutar.

Para obtener más información sobre cómo ejecutar consultas, consulta Ejecutar una consulta interactiva.

Verificar la configuración

Para verificar el estado de tu configuración, consulta la vista INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

PROJECT_ID.`region-REGION`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS[_BY_PROJECT]

Verifica que los conjuntos de datos estén asociados a la reserva correcta en las regiones adecuadas.

Sustituye lo siguiente:
  • Opcional: PROJECT_ID: el ID de tu Google Cloud proyecto. Si no se especifica, se usa el proyecto predeterminado.
  • REGION: cualquier nombre de región del conjunto de datos. Por ejemplo, `region-us`.

Ejemplos

En el siguiente ejemplo se describen los pasos para migrar de CRR a DR con ejemplos prácticos en GoogleSQL. En este ejemplo, supongamos lo siguiente:

  • Estás trabajando en un proyecto llamado myproject.

  • Ya has creado un conjunto de datos llamado mydataset y lo has configurado con CRR.

  • La región principal de mydataset es us-central1 y la secundaria es us-west1.

Para empezar a migrar tu conjunto de datos a la recuperación ante desastres, primero crea una reserva con la edición Enterprise Plus. En este ejemplo, el nombre de la reserva es myreservation.

CREATE RESERVATION `myproject.region-us-central1.myreservation`
OPTIONS (
  slot_capacity = 0,
  edition = ENTERPRISE_PLUS,
  autoscale_max_slots = 50,
  secondary_location = 'us-west-1');

Una vez creada la reserva, puedes adjuntar el conjunto de datos a la reserva. En el siguiente ejemplo se adjunta el conjunto de datos a la reserva:

ALTER SCHEMA
  `myproject.mydataset`
SET OPTIONS (
  failover_reservation = 'myproject.myreservation');

A continuación, comprueba que el conjunto de datos se ha adjuntado correctamente.

SELECT
  failover_reservation_project_id,failover_reservation_name,
FROM
 `myproject`.`region-us-west1`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
 schema_name='mydataset';

Los resultados de esta consulta deberían ser similares a los siguientes:

+---------------------------------+---------------------------+
| failover_reservation_project_id | failover_reservation_name |
+---------------------------------+---------------------------+
| myproject                       | myreservation             |
| myproject                       | myreservation             |
+---------------------------------+---------------------------+

Siguientes pasos