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.
PITR
A recuperação pontual (PITR, na sigla em inglês) 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.
A PITR sempre cria uma nova instância. Não é possível realizar uma PITR em uma instância já existente. 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.
Para instruções detalhadas sobre como realizar a PITR, consulte Usar a recuperação pontual (PITR).
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 do banco de dados que a instância da qual o backup foi tirado.
O Cloud SQL sempre define a capacidade de armazenamento da instância de destino como o valor máximo do tamanho do disco configurado e do disco de backup. O disco de backup é o tamanho do disco quando o backup é realizado.
A capacidade de armazenamento da instância de destino precisa ser pelo menos tão grande quanto a capacidade da instância em que o backup é realizado. A quantidade de armazenamento em uso não precisa ser considerada. Confira a capacidade de armazenamento da instância na página de instâncias do Cloud SQL. Esse requisito é aplicável mesmo que você esteja ou não realizando a PITR de um único banco de dados.
A instância de destino deve estar no estado
RUNNABLE.É possível que a instância de destino tenha um número diferente de núcleos ou uma quantidade diferente de memória do que da 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:
Por exemplo, na figura a seguir, os backups Backup1, Backup2 e Backup3 são da mesma instância de origem.
- 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.