Recuperação de desastres gerenciada

Para proteger seus dados e manter a continuidade dos negócios durante interrupções regionais, é possível configurar e usar a recuperação de desastres gerenciada pelo BigQuery para seus dados e cargas de trabalho do BigQuery.

Visão geral

O BigQuery oferece suporte a cenários de recuperação de desastres no caso de uma interrupção total da região. A recuperação de desastres do BigQuery depende da replicação do conjunto de dados entre regiões para gerenciar o failover de armazenamento. Depois de criar uma réplica de conjunto de dados em uma região secundária, é possível controlar o comportamento do failover para computação e armazenamento para manter a continuidade de negócios durante uma interrupção. Após um failover, é possível acessar a capacidade de computação (slots) e os conjuntos de dados replicados na região promovida. A recuperação de desastres só é compatível com a edição Enterprise Plus.

A recuperação de desastres gerenciada oferece duas opções de failover: rígido e flexível. Um failover rígido promove imediatamente as réplicas de reserva e conjunto de dados da região secundária para se tornarem as primárias. Essa ação é realizada mesmo que a região primária atual esteja off-line e não aguarda a replicação de dados não replicados. Por isso, pode ocorrer perda de dados durante o failover rígido. Todos os jobs que confirmaram dados na região de origem após o valor de replication_time da réplica podem precisar ser executados novamente na região de destino após um failover forçado. Durante um failover forçado, os controles de acesso do conjunto de dados (ACLs), incluindo visualizações autorizadas e concessões de acesso do usuário, que ainda não foram replicados também podem ser perdidos. Para evitar interrupções downstream, inclua etapas de recriação de ACL (por exemplo, usando terraform apply) nos playbooks de failover. Ao contrário de um failover rígido, um failover suave aguarda até que todas as alterações de reserva e conjunto de dados confirmadas na região principal sejam replicadas para a região secundária antes de concluir o processo de failover. Um failover suave requer que as regiões primária e secundária estejam disponíveis. Iniciar um failover suave define o softFailoverStartTime para a reserva. O softFailoverStartTime é limpo após a conclusão do failover parcial.

Para ativar a recuperação de desastres, é necessário 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 do failover. A capacidade de computação em espera na região pareada está incluída na reserva do Enterprise Plus. Em seguida, anexe um conjunto de dados a essa reserva para ativar o failover para esse conjunto de dados. Só é possível anexar um conjunto de dados a uma reserva se ele tiver sido preenchido e tiver os mesmos locais primário e secundário pareado que a reserva. Depois que um conjunto de dados é anexado a uma reserva de failover, somente as reservas do Enterprise Plus podem gravar nesses conjuntos de dados, e não é possível realizar uma promoção de replicação entre regiões. É possível ler conjuntos de dados anexados a uma reserva de failover com qualquer modelo de capacidade. Para mais informações sobre reservas, consulte Introdução ao gerenciamento de cargas de trabalho.

A capacidade de computação da região principal fica disponível na região secundária imediatamente após um failover. Essa disponibilidade se aplica ao valor de referência da reserva, seja ela usada ou não.

Você precisa optar ativamente pelo failover como parte do teste ou em resposta a um desastre real. Você não deve fazer o failover mais de uma vez em um intervalo de 10 minutos. Em cenários de replicação de dados, o preenchimento refere-se ao processo de preencher uma réplica de um conjunto de dados com dados históricos que existiam antes da réplica ser criada ou ficar ativa. Os conjuntos de dados precisam concluir o preenchimento antes que você possa fazer o failover para o conjunto de dados.

O diagrama a seguir mostra a arquitetura da recuperação de desastres gerenciada:

Limitações

As seguintes limitações se aplicam à recuperação de desastres do BigQuery:

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

• Uma reserva de failover pode ter no máximo 1.000 conjuntos de dados anexados.

• Não é possível converter uma reserva atual em uma reserva de failover se ela tiver mais de 1.000 atribuições de reserva.

• Se as consultas fizerem referência a conjuntos de dados anexados a várias reservas de failover no mesmo projeto de administração, todas essas reservas precisarão usar o mesmo local secundário.

• Depois que um conjunto de dados é anexado a uma reserva de failover, somente as reservas do Enterprise Plus podem gravar nele. É possível ler conjuntos de dados anexados usando qualquer modelo de capacidade.

• Para conjuntos de dados que usam recuperação de desastres, os jobs de carregamento e extração não podem usar o pool de slots compartilhados sem custo financeiro. É necessário criar uma atribuição de reserva do tipo PIPELINE, porque somente a edição Enterprise Plus é compatível com a gravação em conjuntos de dados configurados para recuperação de desastres.

• Após um failover, o escalonamento automático depende da disponibilidade da capacidade de computação na região secundária. Apenas o valor de referência da reserva está disponível na região secundária.

• Se a falha na replicação ocorrer durante a criação inicial dos recursos, a reserva não será criada na região secundária, e o failover rígido ou flexível não estará disponível.

• O failover suave exige que as regiões primária e secundária estejam disponíveis.

• Não é possível iniciar um failover parcial se as alterações na configuração da reserva não tiverem sido replicadas para a região secundária. Qualquer erro de replicação, como cota de slots insuficiente na região secundária ou problemas temporários, impede o início do failover parcial.

• Durante um failover parcial ativo, não é possível atualizar a reserva ou os conjuntos de dados anexados, mas ainda é possível ler neles.

• Os jobs em execução em uma reserva de failover durante um failover parcial ativo podem não usar slots de reserva devido a mudanças temporárias de roteamento durante a operação de failover. Esses jobs usam slots de reserva antes do início do failover suave e depois que ele é concluído.

• Após um failover, as consultas programadas não são redirecionadas automaticamente para o novo local principal porque estão vinculadas ao local especificado durante a criação. Para retomar as consultas programadas, é necessário recriá-las no novo local principal.

• A visualização INFORMATION_SCHEMA.RESERVATIONS não inclui detalhes de failover. Para listar eventos de failover para reservas, consulte a visualização INFORMATION_SCHEMA.FAILOVER_HISTORY.

• A visualização INFORMATION_SCHEMA.JOBS contém o histórico de jobs apenas da região em que eles foram executados. O histórico de jobs da região primária não é replicado para a região secundária. Após um failover, o histórico de jobs da região principal não fica visível na região secundária.

Locais

As seguintes regiões estão disponíveis ao criar uma reserva de failover:

Os pares de regiões precisam ser selecionados em AU, CA, DE, EU, EUR5, EUR7, IN ou US. Por exemplo, uma região em US não pode ser pareada com uma região em EU.

Se o conjunto de dados do BigQuery estiver em um local multirregional, não será possível usar os seguintes pares de regiões. Essa limitação é necessária para garantir que a reserva de failover e os dados sejam separados geograficamente após a replicação. Para mais informações sobre regiões contidas em multirregiões, consulte Multirregiões.

• us-central1 - us multirregional
• us-west1 - us multirregional
• eu-west1 - eu multirregional
• eu-west4 - eu multirregional

Antes de começar

1. Verifique se você tem a permissão bigquery.reservations.update do Identity and Access Management (IAM) para atualizar reservas.
2. Verifique se você tem conjuntos de dados configurados para replicação. Para mais informações, consulte Criar um conjunto de dados

Replicação turbo

A recuperação de desastres usa a replicação turbo para acelerar a replicação de dados entre regiões, o que reduz o risco de exposição à perda de dados, minimiza o tempo de inatividade do serviço e ajuda a oferecer suporte a serviços sem interrupções após uma falha temporária regional.

A replicação turbo não se aplica à operação inicial de preenchimento. Depois que a operação inicial de preenchimento for concluída, a replicação turbo será projetada para replicar conjuntos de dados para um único par de região de failover com uma réplica secundária em até 15 minutos, desde que a cota de largura de banda não seja excedida e não haja erros do usuário.

Objetivo do tempo de recuperação

Um objetivo de tempo de recuperação (RTO, na sigla em inglês) é o tempo previsto permitido para recuperação no BigQuery em caso de desastre. Para mais informações sobre o RTO, consulte Noções básicas do planejamento de DR.A recuperação de desastres gerenciada tem um RTO de cinco minutos após o início de um failover. Devido ao RTO, a capacidade fica disponível na região secundária em até cinco minutos após o início do processo de failover.

Objetivo do ponto de recuperação

Um objetivo do ponto de recuperação (RPO, na sigla em inglês) é o momento mais recente em que os dados precisam ser restaurados. Para mais informações sobre o RPO, consulte Noções básicas do planejamento de DR. A recuperação de desastres gerenciada tem um RPO definido por conjunto de dados. O RPO visa manter a réplica secundária em até 15 minutos da primária. Para atender a esse RPO, não é possível exceder a cota de largura de banda e não pode haver erros do usuário.

Cota

Escolha a capacidade de computação na região secundária antes de configurar uma reserva de failover. Se não houver cota disponível na região secundária, não será possível configurar ou atualizar a reserva. Para mais informações, consulte Cotas e limites.

Considerações de cota para reservas de failover

Quando você configura a recuperação de desastres gerenciada, os slots de referência para uma reserva de failover são slots alocados na região secundária. Esses slots alocados aparecem como "usados" na página Cotas e limites do sistema da região secundária, mesmo que a reserva esteja inativa e nenhum failover tenha sido iniciado. Verifique se o projeto de administração tem cota de slots suficiente na região secundária para acomodar a capacidade de referência da reserva de failover. Para mais informações sobre slots alocados e uso de cotas, consulte Noções básicas sobre métricas de slots.

A largura de banda da replicação turbo tem cota. Para mais informações, consulte Cotas e limites.

Preços

A configuração da recuperação de desastres gerenciada requer os seguintes planos de preços:

• Capacidade de computação: você precisa 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 em bytes físicos e por GiB replicado. Para mais informações, consulte Preços de transferência de dados de replicação de dados para replicação turbo.

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

Os clientes só precisam pagar pela capacidade de computação na região principal. A capacidade de computação secundária (com base no valor de referência de reserva) está disponível na região secundária sem custo extra. Slots inativos não podem usar a capacidade de computação secundária, a menos que a reserva tenha falhado.

Se você precisar executar leituras desatualizadas na região secundária, compre mais capacidade de computação.

A recuperação de desastres gerenciada é compatível com o escalonamento fluido do BigQuery. Para garantir o faturamento por segundo sem duração mínima após um failover, ative o escalonamento fluido do BigQuery nas regiões principal e secundária.

Criar ou alterar uma reserva do Enterprise Plus

Antes de anexar um conjunto de dados a uma reserva, crie uma reserva do Enterprise Plus ou altere uma reserva atual e configure-a para recuperação de desastres.

Criar uma reserva

Selecione uma destas opções:

Alterar uma reserva existente

Selecione uma destas opções:

Anexar um conjunto de dados a uma reserva

Para ativar a recuperação de desastres para a reserva criada anteriormente, conclua as etapas a seguir. O conjunto de dados já precisa estar configurado para replicação nas mesmas regiões primária e secundária que a reserva. Para mais informações, consulte Replicação de conjuntos de dados entre regiões.

Desvincular um conjunto de dados de uma reserva

Para interromper o gerenciamento do comportamento de failover de um conjunto de dados por meio de uma reserva, desvincule o conjunto de dados da reserva. Isso não muda a réplica principal atual do conjunto de dados nem remove as réplicas do conjunto de dados. Para mais informações sobre como remover réplicas de conjuntos de dados depois de desconectar um conjunto de dados, consulte Remover réplica de conjunto de dados.

Iniciar um failover

No caso de uma interrupção regional, você precisa fazer o failover manual de sua reserva para o local usado pela réplica. O failover da reserva também inclui todos os conjuntos de dados associados. Para fazer o failover manual de uma reserva, faça o seguinte:

Replicação do monitor

É possível monitorar o status das réplicas do conjunto de dados pelo BigQuery, pelo Cloud Monitoring ou pelas visualizações INFORMATION_SCHEMA.

Para informações sobre como criar alertas nessas métricas, consulte Criar painéis, gráficos e alertas.

Ver o status da replicação com o BigQuery

Para ver o status e a latência de replicação de um conjunto de dados no console doCloud de Confiance , faça o seguinte:

1. No console do Cloud de Confiance , acesse a página BigQuery.

   Acessar o BigQuery

2. No painel Explorer, abra projeto.

3. Clique em Conjuntos de dados.

4. Clique no conjunto de dados que você quer monitorar. Também é possível usar as opções de pesquisa e filtro para encontrar seu conjunto de dados.

5. Na página do conjunto de dados, clique na guia Detalhes.

6. Na seção Réplicas, confira a Latência de replicação e o Status. Para ver mais detalhes, incluindo um gráfico de latência de replicação, clique em Ver detalhes.

Ver o status da replicação com o Cloud Monitoring

O BigQuery fornece as seguintes métricas no Monitoring para ajudar você a monitorar o status da replicação:

• Latência de replicação: a inatividade dos dados na região secundária replicada como parte da replicação entre regiões ou da recuperação de desastres gerenciada. Essa métrica serve como um proxy para seu objetivo de ponto de recuperação (RPO).
• Bytes de saída de rede: o volume de dados faturado (em bytes) replicado da região principal para a secundária. Essa métrica ajuda a monitorar o uso da cota de largura de banda.

Para visualizar essas métricas no Monitoring, faça o seguinte:

1. No console do Cloud de Confiance , acesse a página Monitoring.

   Acessar Monitoring

2. Clique em Metrics Explorer.

3. No campo Selecionar uma métrica, pesquise e selecione Conjunto de dados do BigQuery.

4. Selecione Latência de replicação (bigquery.googleapis.com/storage/replication/dataset_staleness) ou Bytes de saída de rede (bigquery.googleapis.com/storage/replication/network_egress_bytes_count).

5. Clique em Aplicar.

6. Na seção Agregação, selecione um método de agregação. Para a métrica de latência de replicação, recomendamos selecionar 99º percentil. Essa agregação mostra melhor o pior desempenho em comparação com a média ou outras agregações.

7. Opcional: para ver as métricas de um conjunto de dados ou região secundária específica, clique em Adicionar filtro, selecione a opção dataset_id ou location e insira um valor. Se você replicar dados para várias regiões secundárias, poderá agrupar por local para ver as métricas de cada região.

Ver o status da replicação com INFORMATION_SCHEMA

Para determinar o estado das réplicas, consulte a visualização INFORMATION_SCHEMA.SCHEMATA_REPLICAS. 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"

A consulta a seguir retorna os jobs dos últimos sete dias que falhariam se os conjuntos de dados fossem de failover. Para consultar jobs em uma organização, substitua INFORMATION_SCHEMA.JOBS por INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION e omita jobs.query porque a visualização INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION não inclui o texto da consulta:

SELECT
  jobs.project_id AS job_project_id,
  jobs.job_id,
  jobs.job_type,
  jobs.statement_type,
  jobs.reservation_id,
  jobs.edition,
  jobs.destination_table.project_id AS dataset_project_id,
  jobs.destination_table.dataset_id,
  jobs.destination_table.table_id,
  jobs.query
FROM
  `PROJECT_ID.region-LOCATION`.INFORMATION_SCHEMA.JOBS AS jobs
WHERE
  jobs.creation_time
    BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
    AND CURRENT_TIMESTAMP()
  AND jobs.destination_table.project_id = 'DATASET_PROJECT_ID'
  AND jobs.destination_table.dataset_id = 'DATASET_ID'
  AND (jobs.edition IS NULL OR jobs.edition != 'ENTERPRISE_PLUS');

Substitua:

• PROJECT_ID: o ID do projeto em que os jobs foram executados.
• LOCATION: o local.
• DATASET_PROJECT_ID: o ID do projeto em que o conjunto de dados de destino reside.
• DATASET_ID: o ID do conjunto de dados que você planeja anexar a uma reserva de failover.

A seguir

• Consulte INFORMATION_SCHEMA.FAILOVER_HISTORY para conferir os eventos de failover das suas reservas.

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

• Saiba mais sobre confiabilidade.