Sobre a restauração de uma instância

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Nesta página, mostraremos informações que devem ser revisadas antes de restaurar uma instância a partir de um backup ou executar uma recuperação pontual (PITR, na sigla em inglês).

O que acontece durante uma restauração?

Ao restaurar uma instância, os seguintes dados da instância principal são restaurados para a nova instância:

  • Bancos de dados
  • Usuários

A operação de restauração faz com que a instância seja reiniciada.

Recuperação pontual

A recuperação pontual ajuda a recuperar uma instância em um momento específico. Por exemplo, se houver perda de dados devido a um erro, será possível recuperar um banco de dados no estado anterior a esse evento.

Uma recuperação pontual sempre cria uma instância nova. Não é possível executar esse processo em uma instância antiga. A nova instância herda as configurações da instância de origem, semelhante à criação de clones. No entanto, para que a nova instância herde essas configurações, o estado dela precisa ser RUNNABLE.

A recuperação pontual é ativada por padrão quando você cria uma nova instância do Cloud SQL.

Para instruções passo a passo sobre como realizar uma recuperação pontual, consulte Executar uma recuperação pontual.

Dicas gerais sobre como fazer uma restauração

Ao restaurar uma instância a partir de um backup, seja para a mesma instância ou uma diferente, tenha em mente os itens a seguir:

  • A operação de restauração substitui todos os dados na instância de destino.
  • A instância de destino não está disponível para conexões durante a operação de restauração. As conexões atuais se perdem.
  • Se estiver restaurando para uma instância com réplicas de leitura, você precisará excluir todas as réplicas e recriá-las após a conclusão da operação de restauração.
  • A operação de restauração reinicia a instância.

Para instruções passo a passo sobre como realizar uma restauração, consulte:

Dicas e requisitos de restauração para uma instância diferente

Ao restaurar um backup para uma instância diferente, considere as restrições e as práticas recomendadas a seguir:

  • A instância de destino precisa ter a mesma versão e edição do banco de dados que a instância da qual o backup foi tirado.

    Se quiser fazer upgrade da versão do banco de dados da instância, siga as etapas em Fazer upgrade da versão principal do banco de dados no local.

  • A instância de destino precisa ter pelo menos a mesma capacidade de armazenamento que instância sendo copiada no backup. A quantidade de armazenamento em uso não precisa ser considerada. Veja a capacidade de armazenamento da instância na página de instâncias do Cloud SQL.

  • A instância de destino deve estar no estado RUNNABLE.

  • A instância de destino pode usar um número diferente de núcleos e quantidades de memória do que a instância que originou o backup.

  • A instância de destino pode estar em uma região diferente da instância de origem.

  • Durante uma interrupção, ainda é possível recuperar uma lista de backups em um projeto específico. Consulte Como visualizar backups durante uma interrupção.

Limitações de taxa de restauração

É permitido um máximo de três operações de restauração a cada 30 minutos por instância por região e por projeto. Se uma operação de restauração falhar, ela não será considerada para essa cota. Se você atingir o limite, a operação falhará com uma mensagem de erro que informa quando é possível executá-la novamente.

Vamos ver como o Cloud SQL executa a limitação de taxa para restaurações.

O Cloud SQL usa tokens de um bucket para determinar quantas operações de restauração estão disponíveis por vez. Para cada backup, há um bucket para cada projeto e região de destino. As instâncias de destino do mesmo projeto compartilham um bucket se estiverem na mesma região. É possível usar no máximo três tokens em cada bucket para operações de restauração. A cada 10 minutos, um novo token é adicionado ao bucket. Se o bucket estiver cheio, o token estourar.

Cada vez que você emite uma operação de restauração, um token é concedido a partir do bucket. Se a operação for bem-sucedida, o token será removido do bucket. Se falhar, o token será retornado. O diagrama a seguir mostra como isso funciona:

Como os tokens funcionam

Por exemplo, na figura a seguir, os backups Backup1, Backup2 e Backup3 são da mesma instância de origem.

Tokens para limitação da taxa de operação de restauração

  • Cada backup (Backup1, Backup2 e Backup3) tem o próprio bucket de tokens para operações de restauração que visam instâncias diferentes no Projeto 1 na Região A (Bucket11A, Bucket21A e Bucket31A). Como cada backup tem o próprio bucket, é possível restaurar cada backup para a mesma instância três vezes a cada 30 minutos.
  • Cada backup tem um bucket para um projeto e uma região separados. Por exemplo, se houver cinco projetos em uma região, haverá cinco buckets para esse backup nessa região, um em cada projeto. Na figura anterior, temos dois projetos na região A: Projeto 1 e Projeto n.
    • O Backup1 tem dois buckets de tokens para operações de restauração na região A. Um bucket para o projeto 1 (bucket11A) e um bucket para o projeto n (bucket1nA).
    • Da mesma forma, o Backup3 tem dois buckets para operações de restauração na região A. Uma para o Projeto 1 (Bucket31A) e outra para o Projeto n (Bucket3nA).
  • O Backup3 tem um bucket na região B, para o Projeto 1, porque todas as instâncias no mesmo projeto de destino e na mesma região de destino compartilham um bucket.

A seguir