Migre para a recuperação de desastres gerida

Esta página descreve como migrar da replicação entre regiões do BigQuery para a recuperação de desastres gerida do BigQuery.

Vista geral

A replicação entre regiões (CRR) e a recuperação de desastres (DR) gerida do BigQuery são funcionalidades concebidas para melhorar a disponibilidade dos dados e as capacidades de recuperação de desastres. No entanto, gerem as indisponibilidades regionais de formas diferentes. O CRR não permite a promoção da réplica secundária se a região principal estiver indisponível. Por outro lado, a DR oferece uma proteção mais abrangente, permitindo uma comutação por falha para a réplica secundária, mesmo que a região principal esteja indisponível. Com a CRR, apenas o armazenamento é replicado, enquanto com a DR, o armazenamento e a capacidade de computação são replicados.

A tabela seguinte descreve as capacidades das funcionalidades de CRR e DR:

Funcionalidade CRR RD
Processo de replicação inicial Usa a CRR para replicar inicialmente o conjunto de dados. O carregamento inicial é replicado anteriormente com o CRR antes de migrar um conjunto de dados do CRR para um conjunto de dados do DR.
Replicação de promoções Usa a replicação padrão. Usa a replicação turbo.
Processo de promoção Promove ao nível do conjunto de dados. Promove ao nível da reserva (promoção de reserva alternativa e conjunto de dados). É possível anexar muitos conjuntos de dados a uma reserva de alternativa. A promoção ao nível do conjunto de dados não está disponível com o DR.
Execução de promoções Através da IU ou do comando DDL baseado em SQL para cada conjunto de dados. Não existe suporte para CLI, bibliotecas de clientes, API nem Terraform. Através da IU ou do comando DDL baseado em SQL para cada reserva de EPE. Não existe suporte para CLI, bibliotecas de clientes, API nem Terraform.
Modo de comutação por falha Failover suave. Comutação por falha rígida.
Requisito da edição Qualquer modelo de capacidade. Edição Enterprise Plus.
Limitações Limitações da CRR. Inclui limitações de CRR e limitações de DR.
Acesso de escrita Os trabalhos executados em qualquer modelo de capacidade podem escrever em conjuntos de dados replicados na região principal. A propriedade secundária é sempre só de leitura. Apenas os trabalhos executados em reservas do Enterprise Plus podem escrever em conjuntos de dados replicados na região principal. O conjunto de dados secundário e as réplicas de reserva são sempre só de leitura.
Acesso de leitura As tarefas executadas em qualquer modelo de capacidade podem ler a partir de conjuntos de dados replicados. As tarefas executadas em qualquer modelo de capacidade podem ler a partir de conjuntos de dados replicados.

Implicações da migração

As secções seguintes fornecem uma vista geral das alterações de custos e capacidades que ocorrem quando migra para a DR.

Implicações de custos

Considere as seguintes implicações de custos quando migrar do CRR para o DR:

  • A DR só suporta acesso de escrita a partir da edição Enterprise Plus, que incorre em custos de computação mais elevados. Pode ler a partir de qualquer modelo de capacidade, pelo que os custos de leitura para tarefas existentes não se alteram.

  • A DR usa a replicação turbo, que incorre em custos adicionais consoante o par de regiões.

  • Os preços de armazenamento são os mesmos para o CRR e o DR.

Para mais informações sobre preços, consulte a secção Preços.

Implicações das capacidades

Considere as seguintes implicações de capacidade quando migrar do CRR para o DR:

  • A DR só suporta a comutação por falha ao nível da reserva. Todas as tarefas existentes que dependam da comutação por falha ao nível do conjunto de dados falham.

  • Apenas as consultas da edição Enterprise Plus podem escrever no conjunto de dados assim que este for anexado à reserva de DR. Todas as tarefas de gravação existentes que não usem uma edição Enterprise Plus para a respetiva capacidade de computação falham.

Antes de começar

Antes de iniciar a migração, familiarize-se com os conceitos de replicação entre regiões e recuperação de desastres gerida.

Para migrar para a DR, tem de cumprir os seguintes pré-requisitos:

  • Tem um Google Cloud projeto ativo com o BigQuery ativado.

  • Criou e replicou conjuntos de dados com o CRR.

  • Os conjuntos de dados têm as mesmas localizações principais e secundárias que quer usar para a DR.

  • Tem as autorizações necessárias para trabalhar com o DR. Para mais informações sobre as autorizações, consulte a secção Antes de começar.

Migre do CRR para o DR

As secções seguintes descrevem como migrar os conjuntos de dados do CRR para o DR. Parte do princípio de que já configurou os conjuntos de dados para o CRR.

Crie uma reserva de alternativa

Para ativar a recuperação de desastres, tem de criar uma reserva de comutação por falha na região principal. Configure a sua reserva com a região principal e secundária adequadas. As regiões primária e secundária devem corresponder às regiões de todos os conjuntos de dados de CRR que pretende migrar para DR. Para criar uma reserva de comutação por falha, escolha uma das seguintes opções:

Consola

  1. Na Google Cloud consola, aceda à página BigQuery.

    Aceda ao BigQuery

  2. No menu de navegação, clique em Gestão de capacidade e, de seguida, clique em Criar reserva.

  3. No campo Nome da reserva, introduza um nome para a reserva.

  4. Na lista Localização, selecione a localização.

  5. Na lista Edição, selecione a edição Enterprise Plus.

  6. Na lista do seletor de tamanho máximo da reserva, selecione o tamanho máximo da reserva.

  7. Opcional: no campo Intervalos de base, introduza o número de intervalos de base para a reserva.

    O número de espaços de dimensionamento automático disponíveis é determinado subtraindo o valor de Espaços de base ao valor de Tamanho máximo da reserva. Por exemplo, se criar uma reserva com 100 espaços base e um tamanho máximo de reserva de 400, a sua reserva tem 300 espaços de escalabilidade automática. Para mais informações sobre os horários de base, consulte o artigo Usar reservas com horários de base e de escalabilidade automática.

  8. Na lista Localização secundária, selecione a localização secundária.

  9. Para desativar a partilha de espaços inativos e usar apenas a capacidade de espaço especificada, clique no botão Ignorar espaços inativos.

  10. Para expandir a secção Definições avançadas, clique na seta de expansão .

  11. Opcional: para definir a simultaneidade de tarefas alvo, clique no botão Substituir a simultaneidade de tarefas alvo automática para o ativar e, de seguida, introduza um valor para Simultaneidade de tarefas alvo. A discriminação dos espaços é apresentada na tabela Estimativa de custos. É apresentado um resumo da reserva na tabela Resumo da capacidade.

  12. Clique em Guardar.

A nova reserva fica visível no separador Reservas de horários.

SQL

Para criar uma reserva, use a CREATE RESERVATION declaração de linguagem de definição de dados (LDD).

  1. Na Google Cloud consola, aceda à página BigQuery.

    Aceda ao BigQuery

  2. No editor de consultas, introduza a seguinte declaração:

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

    Substitua o seguinte:

    • ADMIN_PROJECT_ID: o ID do projeto do projeto de administração que detém o recurso de reserva.
    • LOCATION: a localização da reserva. Se selecionar uma localização do BigQuery Omni, a sua opção de edição está limitada à Enterprise Edition.

    • RESERVATION_NAME: o nome da reserva.

      O nome tem de começar e terminar com uma letra minúscula ou um número e conter apenas letras minúsculas, números e traços.

    • NUMBER_OF_BASELINE_SLOTS: o número de espaços de base a atribuir à reserva. Não pode definir a opção slot_capacity e a opção edition na mesma reserva.
    • SECONDARY_LOCATION: a localização secundária da reserva. No caso de uma indisponibilidade, todos os conjuntos de dados anexados a esta reserva vão ser transferidos para esta localização.

  3. Clique em Executar.

Para mais informações sobre como executar consultas, consulte o artigo Execute uma consulta interativa.

Anexe o conjunto de dados à reserva

Depois de criar a reserva de alternativa, anexe o conjunto de dados ou os conjuntos de dados de várias regiões à reserva. Isto ativa a comutação por falha para todos os conjuntos de dados anexados. Para anexar o conjunto de dados à reserva, escolha uma das seguintes opções:

Consola

  1. Na Google Cloud consola, aceda à página BigQuery.

    Aceda ao BigQuery

  2. No menu de navegação, clique em Gestão da capacidade e, de seguida, clique no separador Reservas de horários.

  3. Clique na reserva à qual quer anexar um conjunto de dados.

  4. Clique no separador Recuperação de desastres.

  5. Clique em Adicionar conjunto de dados de alternativa.

  6. Introduza o nome do conjunto de dados que quer associar à reserva.

  7. Clique em Adicionar.

SQL

Para anexar um conjunto de dados a uma reserva, use a declaração DDL ALTER SCHEMA SET OPTIONS.

  1. Na Google Cloud consola, aceda à página BigQuery.

    Aceda ao BigQuery

  2. No editor de consultas, introduza a seguinte declaração:

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

    Substitua o seguinte:

    • DATASET_NAME: o nome do conjunto de dados.

    • ADMIN_PROJECT_ID.RESERVATION_NAME: o nome da reserva à qual quer associar o conjunto de dados.

  3. Clique em Executar.

Para mais informações sobre como executar consultas, consulte o artigo Execute uma consulta interativa.

Valide a configuração

Para verificar o estado da sua configuração, consulte a INFORMATION_SCHEMA.SCHEMATA_REPLICAS vista.

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

Verifique se os conjuntos de dados estão anexados à reserva correta nas regiões corretas.

Substitua o seguinte:
  • Opcional: PROJECT_ID: o ID do seu projeto do Google Cloud Google Cloud. Se não for especificado, é usado o projeto predefinido.
  • REGION: qualquer nome da região do conjunto de dados. Por exemplo, `region-us`.

Exemplos

O exemplo seguinte explica os passos para migrar do CRR para o DR com exemplos práticos através do GoogleSQL. Para este exemplo, suponha o seguinte:

  • Está a trabalhar num projeto com o nome myproject.

  • Já criou um conjunto de dados com o nome mydataset e configurou-o com CRR.

  • A região principal de mydataset é us-central1 e a região secundária é us-west1.

Para começar a migrar o seu conjunto de dados para a DR, crie primeiro uma reserva com a edição Enterprise Plus. Neste exemplo, o nome da reserva é myreservation.

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

Depois de criar a reserva, pode anexar o conjunto de dados à reserva. O exemplo seguinte anexa o conjunto de dados à reserva:

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

Em seguida, verifique se o conjunto de dados foi anexado com êxito.

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

Os resultados desta consulta devem ser semelhantes aos seguintes:

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

O que se segue?