Recuperação de desastres gerida

Este documento apresenta uma vista geral da recuperação de desastres gerida pelo BigQuery e como a implementar para os seus dados e cargas de trabalho.

Vista geral

O BigQuery suporta cenários de recuperação de desastres no caso de uma interrupção total da região. A recuperação de desastres do BigQuery baseia-se na replicação de conjuntos de dados entre regiões para gerir a comutação por falha do armazenamento. Depois de criar uma réplica do conjunto de dados numa região secundária, pode controlar o comportamento de ativação pós-falha para computação e armazenamento de modo a manter a continuidade da empresa durante uma indisponibilidade. Após uma comutação por falha, pode aceder à capacidade de computação (slots) e aos conjuntos de dados replicados na região promovida. A recuperação de desastres só é suportada com a edição Enterprise Plus.

A recuperação de desastres gerida oferece duas opções de comutação por falha: comutação por falha rígida e comutação por falha flexível. Uma comutação por falha rígida promove imediatamente a reserva e as réplicas do conjunto de dados da região secundária para se tornarem primárias. Esta ação prossegue mesmo que a região principal atual esteja offline e não aguarda a replicação de dados não replicados. Por este motivo, pode ocorrer perda de dados durante a comutação por falha forçada. Quaisquer tarefas que tenham confirmado dados na região de origem antes do valor da réplica de replication_time podem ter de ser executadas novamente na região de destino após a comutação por falha. Ao contrário de uma comutação por falha forçada, uma comutação por falha suave aguarda até que todas as alterações de conjuntos de dados e reservas confirmadas na região principal sejam replicadas para a região secundária antes de concluir o processo de comutação por falha. Uma comutação por falha suave requer que a região principal e a secundária estejam disponíveis. Iniciar uma comutação por falha suave define o elemento softFailoverStartTime para a reserva. O softFailoverStartTime é limpo quando a comutação por falha suave é concluída.

Para ativar a recuperação de desastres, tem de criar uma reserva da edição Enterprise Plus na região principal, que é a região em que o conjunto de dados se encontra antes da comutação por falha. A capacidade de computação em espera na região sincronizada está incluída na reserva do Enterprise Plus. Em seguida, anexa um conjunto de dados a esta reserva para ativar a comutação por falha para esse conjunto de dados. Só pode anexar um conjunto de dados a uma reserva se o conjunto de dados for preenchido e tiver as mesmas localizações principais e secundárias sincronizadas que a reserva. Depois de um conjunto de dados ser anexado a uma reserva de alternativa, apenas as reservas do Enterprise Plus podem escrever nesses conjuntos de dados, e não pode fazer uma promoção de replicação entre regiões no conjunto de dados. Pode ler a partir de conjuntos de dados anexados a uma reserva de alternativa com qualquer modelo de capacidade. Para mais informações sobre reservas, consulte o artigo Introdução à gestão de cargas de trabalho.

A capacidade de computação da sua região principal está disponível na região secundária imediatamente após uma comutação por falha. Esta disponibilidade aplica-se à sua base de referência de reserva, quer seja usada ou não.

Tem de optar ativamente pela comutação por falha como parte dos testes ou em resposta a um desastre real. Não deve fazer failover mais do que uma vez num período de 10 minutos. Em cenários de replicação de dados, o repreenchimento refere-se ao processo de preenchimento de uma réplica de um conjunto de dados com dados do histórico que existiam antes de a réplica ser criada ou ficar ativa. Os conjuntos de dados têm de concluir o preenchimento antes de poderem ser transferidos para o conjunto de dados.

O diagrama seguinte mostra a arquitetura da recuperação de desastres gerida:

Limitações

Aplicam-se as seguintes limitações à recuperação de desastres do BigQuery:

• A recuperação de desastres do BigQuery está sujeita às mesmas limitações que a replicação de conjuntos de dados entre regiões.

• A criação de uma escala automática após uma comutação por falha depende da disponibilidade de capacidade de computação na região secundária. Apenas a base de referência de reservas está disponível na região secundária.

• A INFORMATION_SCHEMA.RESERVATIONS vista não tem detalhes de alternativa.

• Se tiver várias reservas de alternativa com o mesmo projeto de administração, mas cujos conjuntos de dados anexados usam localizações secundárias diferentes, não use uma reserva de alternativa com os conjuntos de dados anexados a uma reserva de alternativa diferente.

• Se quiser converter uma reserva existente numa reserva de alternativa, a reserva existente não pode ter mais de 1000 atribuições de reservas.

• Uma reserva de alternativa não pode ter mais de 1000 conjuntos de dados anexados.

• A comutação por falha suave só pode ser acionada se as regiões de origem e de destino estiverem disponíveis.

• Não é possível acionar a comutação por falha suave se existirem erros temporários ou de outro tipo durante a replicação de reservas. Por exemplo, se existir uma quota de vagas insuficiente na região secundária para a atualização da reserva.

• Não é possível atualizar a reserva e os conjuntos de dados anexados durante uma comutação por falha suave ativa, mas ainda é possível lê-los.

• Os trabalhos executados numa reserva de ativação pós-falha durante uma ativação pós-falha temporária ativa podem não ser executados na reserva devido a alterações transitórias no conjunto de dados e no encaminhamento de reservas durante a operação de ativação pós-falha. No entanto, estas tarefas vão usar os slots de reserva antes de ser iniciada qualquer comutação por falha suave e depois de ser concluída.

Localizações

As seguintes regiões estão disponíveis quando cria uma reserva de alternativa:

Código da localização	Nome da região	Descrição da região
ASIA
	ASIA-EAST1	Taiwan
	ASIA-SOUTHEAST1	Singapura
AU
	AUSTRALIA-SOUTHEAST1	Sydney
	AUSTRALIA-SOUTHEAST2	Melbourne
CA
	NORTHAMERICA-NORTHEAST1	Montréal
	NORTHAMERICA-NORTHEAST2	Toronto
DE
	EUROPE-WEST3	Frankfurt
	EUROPE-WEST10	Berlim
EU
	EU	Multirregional da UE
	EUROPE-CENTRAL2	Varsóvia
	EUROPE-NORTH1	Finlândia
	EUROPE-SOUTHWEST1	Madrid
	EUROPE-WEST1	Bélgica
	EUROPE-WEST3	Frankfurt
	EUROPE-WEST4	Países Baixos
	EUROPE-WEST8	Milão
	EUROPE-WEST9	Paris
IN
	ASIA-SOUTH1	Mumbai
	ASIA-SOUTH2	Deli
US
	US	Multirregião dos EUA
	US-CENTRAL1	Iowa
	US-EAST1	Carolina do Sul
	US-EAST4	Virgínia do Norte
	US-EAST5	Columbus
	US-SOUTH1	Dallas
	US-WEST1	Oregon
	US-WEST2	Los Angeles
	US-WEST3	Salt Lake City
	US-WEST4	Las Vegas

Tem de selecionar pares de regiões em ASIA, AU, CA, DE, EU, IN ou US. Por exemplo, não é possível sincronizar uma região no US com uma região no EU.

Se o seu conjunto de dados do BigQuery estiver numa localização multirregional, não pode usar os seguintes pares de regiões. Esta limitação é necessária para garantir que a reserva e os dados de alternativa estão geograficamente separados após a replicação. Para mais informações sobre as regiões contidas em várias regiões, consulte o artigo Várias regiões.

• us-central1 - us multirregião
• us-west1 - us multirregião
• eu-west1 - eu multirregião
• eu-west4 - eu multirregião

Antes de começar

1. Verifique se tem a autorização da bigquery.reservations.update gestão de identidade e de acesso (IAM) para atualizar reservas.
2. Confirme que tem conjuntos de dados existentes configurados para replicação. Para mais informações, consulte o artigo Replique um conjunto de dados.

Replicação turbo

A recuperação de desastres usa a replicação turbo para uma replicação de dados mais rápida entre regiões, o que reduz o risco de exposição à perda de dados, minimiza a inatividade do serviço e ajuda a suportar um serviço ininterrupto após uma indisponibilidade regional.

A replicação turbo não se aplica à operação de repreenchimento inicial. Após a conclusão da operação de preenchimento inicial, a replicação turbo tem como objetivo replicar conjuntos de dados para um único par de regiões de alternativa com uma réplica secundária no prazo de 15 minutos, desde que a quota de largura de banda não seja excedida e não existam erros do utilizador.

Objetivo de tempo de recuperação

Um objetivo de tempo de recuperação (OTR) é o tempo alvo permitido para a recuperação no BigQuery em caso de desastre. Para mais informações sobre o RTO, consulte o artigo Noções básicas do planeamento de recuperação de desastres.A recuperação de desastres gerida tem um RTO de cinco minutos após iniciar uma comutação por falha. Devido ao RTO, a capacidade está disponível na região secundária no prazo de cinco minutos após o início do processo de comutação por falha.

Objetivo de ponto de recuperação

Um objetivo de ponto de recuperação (RPO) é o ponto mais recente no tempo a partir do qual os dados têm de poder ser restaurados. Para mais informações sobre o RPO, consulte o artigo Noções básicas do planeamento de DR. A recuperação de desastres gerida tem um RPO definido por conjunto de dados. O RPO visa manter a réplica secundária no prazo de 15 minutos da principal. Para cumprir este RPO, não pode exceder a quota de largura de banda e não pode haver erros do utilizador.

Quota

Tem de ter a capacidade de computação escolhida na região secundária antes de configurar uma reserva de comutação por falha. Se não houver quota disponível na região secundária, não pode configurar nem atualizar a reserva. Para mais informações, consulte o artigo Quotas e limites.

A largura de banda da replicação turbo tem uma quota. Para mais informações, consulte a secção Quotas e limites.

Preços

A configuração da recuperação de desastres gerida requer os seguintes planos de pagamento:

• Capacidade de computação: tem de comprar a edição Enterprise Plus.

• Replicação turbo: a recuperação de desastres depende da replicação turbo durante a replicação. A cobrança é feita com base nos bytes físicos e numa base replicada por GiB físico. Para mais informações, consulte os preços da transferência de dados de replicação de dados para a replicação turbo.

• Armazenamento: os bytes de armazenamento na região secundária são faturados ao mesmo preço que os bytes de armazenamento na região principal. Para mais informações, consulte os preços de armazenamento.

Os clientes só têm de pagar a capacidade de computação na região principal. A capacidade de computação secundária (com base na base de referência da reserva) está disponível na região secundária sem custos adicionais. Os slots inativos não podem usar a capacidade de computação secundária, a menos que a reserva tenha sido transferida.

Se precisar de realizar leituras desatualizadas na região secundária, tem de comprar capacidade de computação adicional.

Crie ou altere uma reserva do Enterprise Plus

Antes de anexar um conjunto de dados a uma reserva, tem de criar uma reserva Enterprise Plus ou alterar uma reserva existente e configurá-la para recuperação de desastres.

Crie uma reserva

Selecione 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.

Alterar uma reserva existente

Selecione 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.

3. Clique no separador Reservas de horários.

4. Encontre a reserva que quer atualizar.

5. Clique em Ações de reservas e, de seguida, clique em Editar.

6. No campo Localização secundária, introduza a localização secundária.

7. Clique em Guardar.

SQL

Para adicionar ou alterar uma localização secundária a uma reserva, use a ALTER RESERVATION SET OPTIONS declaração DDL.

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

   Aceda ao BigQuery

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

   ALTER RESERVATION
     `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
   SET OPTIONS (
     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, por exemplo, europe-west9.

   • 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.

   • 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 um conjunto de dados a uma reserva

Para ativar a recuperação de desastres para a reserva criada anteriormente, conclua os passos seguintes. O conjunto de dados já tem de estar configurado para replicação nas mesmas regiões principal e secundária que a reserva. Para mais informações, consulte o artigo Replicação de conjuntos de dados entre regiõ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.

Desassocie um conjunto de dados de uma reserva

Para parar de gerir o comportamento de comutação por falha de um conjunto de dados através de uma reserva, desassocie o conjunto de dados da reserva. Isto não altera a réplica principal atual do conjunto de dados nem remove réplicas do conjunto de dados existentes. Para mais informações sobre como remover réplicas de conjuntos de dados depois de desanexar um conjunto de dados, consulte o artigo Remova a réplica do conjunto de dados.

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 da qual quer desanexar um conjunto de dados.

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

5. Expanda a opção Ações para a réplica principal do conjunto de dados.

6. Clique em Remover.

SQL

Para desassociar um conjunto de dados de 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 = NULL);

   Substitua o seguinte:

   • DATASET_NAME: o nome do conjunto de dados.

3. Clique em Executar.

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

Inicie uma comutação por falha

Em caso de indisponibilidade regional, tem de fazer manualmente a comutação por falha da sua reserva para a localização usada pela réplica. A comutação por falha da reserva também inclui todos os conjuntos de dados associados. Para fazer manualmente uma comutação por falha de uma reserva, faça o seguinte:

Consola

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

   Aceda ao BigQuery

2. No menu de navegação, clique em Recuperação de desastres.

3. Clique no nome da reserva para a qual quer fazer failover.

4. Selecione Modo de comutação por falha rígida (predefinição) ou Modo de comutação por falha flexível.

5. Clique em Failover.

SQL

Para adicionar ou alterar uma localização secundária numa reserva, use a declaração DDL ALTER RESERVATION SET OPTIONS e defina is_primary como TRUE.

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

   Aceda ao BigQuery

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

   ALTER RESERVATION
     `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
   SET OPTIONS (
     is_primary = TRUE, failover_mode=FAILOVER_MODE);

   Substitua o seguinte:

   • ADMIN_PROJECT_ID: o ID do projeto do projeto de administração que detém o recurso de reserva.
   • LOCATION: a nova localização principal da reserva, ou seja, a localização secundária atual antes da comutação por falha. Por exemplo, europe-west9.

   • 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.

   • PRIMARY_STATUS: um estado booleano que declara se a reserva é a réplica principal.

   • FAILOVER_MODE: um parâmetro opcional usado para descrever o modo de alternativa. Pode definir esta opção como HARD ou SOFT. Se este parâmetro não for especificado, é usado HARD por predefinição.

3. Clique em Executar.

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

Monitorização

Para determinar o estado das suas réplicas, consulte a vista INFORMATION_SCHEMA.SCHEMATA_REPLICAS. Por exemplo:

SELECT
  schema_name,
  replica_name,
  creation_complete,
  replica_primary_assigned,
  replica_primary_assignment_complete
FROM
  `region-LOCATION`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
  schema_name="my_dataset"

Aviso: depois de um conjunto de dados ser anexado a uma reserva de alternativa, apenas as reservas do Enterprise Plus podem escrever nesse conjunto de dados. Pode ler a partir de conjuntos de dados anexados a uma reserva de alternativa com qualquer modelo de capacidade.

A seguinte consulta devolve as tarefas dos últimos sete dias que falhariam se os respetivos conjuntos de dados fossem conjuntos de dados de comutação por falha:

WITH
  non_epe_reservations AS (
    SELECT project_id, reservation_name
    FROM `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.RESERVATIONS
    WHERE edition != 'ENTERPRISE_PLUS'
  )
SELECT *
FROM
  (
    SELECT job_id
    FROM
      (
        SELECT
          job_id,
          reservation_id,
          ARRAY_CONCAT(referenced_tables, [destination_table]) AS all_referenced_tables,
          query
        FROM
          `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.JOBS
        WHERE
          creation_time
          BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
          AND CURRENT_TIMESTAMP()
      ) A,
      UNNEST(all_referenced_tables) AS referenced_table
  ) jobs
LEFT OUTER JOIN non_epe_reservations
  ON (
    jobs.reservation_id = CONCAT(
      non_epe_reservations.project_id, ':', 'LOCATION', '.', non_epe_reservations.reservation_name))
WHERE
  CONCAT(jobs.project_id, ':', jobs.dataset_id)
  IN UNNEST(
    [
      'PROJECT_ID:DATASET_ID',
      'PROJECT_ID:DATASET_ID']);

Substitua o seguinte:

• PROJECT_ID: o ID do projeto.
• DATASET_ID: o ID do conjunto de dados.
• LOCATION: a localização.

O que se segue?

• Saiba mais sobre a replicação de conjuntos de dados entre regiões.

• Saiba mais acerca da fiabilidade.