É possível restaurar um backup de um banco de dados do Spanner em um novo banco de dados. O
banco de dados restaurado terá todos os dados e o esquema do banco de dados original
no version_time
do backup, incluindo todas as opções de banco de dados definidas
com o comando ALTER DATABASE SET OPTIONS
. No entanto, o seguinte não está incluído no banco de dados restaurado:
- Permissões do IAM (exceto as herdadas da instância que contém o banco de dados restaurado). Você precisa aplicar as permissões adequadas do IAM após a conclusão da restauração.
- Dados internos de qualquer fluxo de alterações.
- Time to live (TTL) definido por uma política de exclusão de linha. Você precisa reconfigurar essas políticas depois que a restauração for concluída. Para mais informações, consulte Backups e TTL.
- Pontos de divisão criados ao pré-dividir um banco de dados. Para mais informações, consulte Visão geral da pré-divisão.
Quando você restaura de um backup, o banco de dados restaurado fica na mesma instância, região e projeto do backup de origem. Se você precisar restaurar o backup em uma região ou projeto diferente por motivos de conformidade ou continuidade dos negócios, copie o backup para uma instância em uma região ou projeto separado e restaure do backup copiado.
É possível usar a restauração de um backup das seguintes maneiras:
- No console doGoogle Cloud
- Como usar a Google Cloud CLI
- com as bibliotecas de cliente
- Como usar as APIs REST ou RPC
Como funciona a restauração de um banco de dados a partir de um backup
Ao restaurar um banco de dados do Spanner, especifique um backup de origem e um novo banco de dados de destino. Não é possível restaurar para um banco de dados atual.
O banco de dados recém-restaurado precisa estar no mesmo projeto que o backup e em uma instância com a mesma configuração de instância e a mesma edição do Spanner (ou de nível superior) que o backup. Por exemplo, se um backup estiver em uma instância configurada em us-west3
e
usar a edição Enterprise, ele poderá ser restaurado para qualquer instância no
projeto que também esteja configurada em us-west3
e use a
edição Enterprise. Se você restaurar um backup de uma instância da edição Enterprise em uma instância da edição Standard, a restauração poderá falhar se o banco de dados usar recursos da edição Enterprise. A capacidade de computação das instâncias não precisa ser a mesma.
O processo de restauração foi projetado para alta disponibilidade. O banco de dados pode ser restaurado desde que a maioria das regiões e zonas da instância esteja disponível.
Para restaurar um backup ativado para CMEK, a chave e a versão da chave precisam estar disponíveis para o Spanner. Por padrão, o banco de dados restaurado usa as mesmas configurações de criptografia do backup. É possível substituir esse comportamento especificando uma configuração de criptografia diferente ao restaurar o banco de dados. Para mais informações, consulte como restaurar um backup ativado para CMEK.
Restaurar um backup para outra região ou projeto
Se você precisar restaurar o backup para uma região ou projeto diferente, primeiro copie o backup para a região ou o projeto escolhido. Os backups copiados podem ser restaurados assim que a cópia terminar. É possível restaurar o backup na instância de destino (desde que ela use a edição como a instância de backup de origem) ou em qualquer instância que tenha a mesma configuração e a mesma edição (ou uma de nível superior) da instância de destino. Antes de restaurar, verifique se a instância de destino tem nós ou unidades de processamento suficientes provisionados para oferecer suporte ao tamanho do banco de dados de acordo com o limite de armazenamento de 10 TB por nó. Ou seja, você precisa de pelo menos dois nós para restaurar um backup de 20 TB. Se você copiou o backup para um projeto diferente e quer restaurá-lo lá, verifique se o projeto de destino tem cotas de nós suficientes para a restauração. A restauração de um backup copiado funciona da mesma forma que uma restauração normal.
Estados de restauração
Um banco de dados restaurado passa por três estados, rastreados por duas operações de longa duração.
CREATING
: o Spanner começa a restauração criando um novo banco de dados e ativando arquivos do backup. Durante esse estado inicialCREATING
, o banco de dados restaurado ainda não está pronto para uso. Esse estado normalmente é concluído em uma hora. Quando o estadoCREATING
for concluído, seu banco de dados estará pronto para uso.Para acompanhar o progresso desse estado, consulte a operação de restauração de longa duração que o Spanner disponibiliza durante esse processo. Ele retorna um objeto
RestoreDatabaseMetadata
.Observe as seguintes ressalvas sobre o estado
CREATING
:- Se você estiver restaurando para uma instância diferente, a operação de restauração pertencerá à instância que contém o banco de dados restaurado, não à instância que contém o backup.
- O Spanner não permite excluir o backup enquanto ele está
sendo restaurado. É possível excluir o bucket depois que a restauração for concluída e o banco de dados entrar no estado
READY
. - Uma instância pode ter no máximo dez bancos de dados no estado
CREATING
devido à restauração de backups. Não será possível restaurar outro backup para a instância até que um dos dez bancos de dados restaurados faça a transição para o estadoREADY_OPTIMIZING
ouREADY
.
READY_OPTIMIZING
: depois que o Spanner monta o backup, ele começa a copiar os dados para o novo banco de dados e otimiza o tamanho armazenado. Seu banco de dados está pronto para uso durante esse processo. Essa fase da restauração geralmente leva algumas horas para ser concluída em bancos de dados com menos de 100 TB.Embora seja possível usar seu banco de dados normalmente durante o
READY_OPTIMIZING
, as seguintes ressalvas se aplicam:- As latências de leitura podem ser um pouco maiores do que o normal.
- As métricas de armazenamento mostram o tamanho do novo banco de dados, não do backup. Portanto, com a transferência de dados ainda em andamento, as métricas de armazenamento do Spanner podem mostrar resultados que não refletem o tamanho total de todos os seus dados.
- Assim como no estado
CREATING
, o Spanner não permite excluir o backup ativado.
O Spanner disponibiliza outra operação de restauração de longa duração durante esse estado, desta vez retornando um objeto de metadados
OptimizeRestoredDatabaseMetadata
.READY
: após a conclusão da operação de cópia e otimização, o banco de dados faz a transição para o estadoREADY
. O banco de dados é totalmente restaurado e não faz mais referência nem exige o backup.
Controle de acesso (IAM)
A função spanner.restoreAdmin
concede permissão para restaurar de um backup.
Saiba mais em Controle de acesso com o IAM.
Os seguintes papéis também têm acesso às operações de restauração do Spanner:
spanner.admin
: tem acesso total à restauração. Essa função tem acesso completo a todos os recursos do Spanner.owner
: tem acesso total à restauração.editor
: tem acesso total à restauração.viewer
: tem acesso para visualizar restaurações e operações de restauração. Esse papel não pode criar, atualizar, excluir ou copiar um backup.
Preços
Não há cobrança pela restauração de um backup.
A seguir
- Para restaurar um banco de dados de um backup, consulte Restaurar de um backup.