Visão geral da restauração

É possível restaurar um backup de um banco de dados do Spanner para 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 ALTER DATABASE SET OPTIONS comando. No entanto, o seguinte não está incluído no banco de dados restaurado:

  • Permissões do Identity and Access Management (IAM), exceto as herdadas da instância que contém o banco de dados restaurado. É necessário aplicar as permissões apropriadas do IAM após a conclusão da restauração.
  • Dados internos de qualquer fluxo de alterações.
  • Tempo de vida (TTL) definido por uma política de exclusão de linhas. É necessário reconfigurar essas políticas após a conclusão da restauração. 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.

Se você precisar restaurar um backup em uma região ou projeto diferente por motivos de conformidade ou continuidade dos negócios, você pode copiar o backup para uma instância em uma região ou projeto separado e restaurar o backup copiado.

É possível restaurar um backup das seguintes maneiras:

Como funciona a restauração de um banco de dados 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. Restaure o banco de dados para o mesmo projeto do backup. A instância de destino precisa usar a mesma configuração de instância da instância de backup. A instância de destino permite usar uma capacidade de computação diferente do que a instância de origem.

Ao restaurar um banco de dados, considere as seguintes regras de compatibilidade para a edição do Spanner:

  • O Spanner oferece suporte à restauração do banco de dados para uma instância que usa a mesma edição ou uma edição de nível superior da instância de backup.
  • É possível restaurar o banco de dados para uma instância que usa uma edição de nível inferior. No entanto, a operação de restauração falha se o banco de dados usar recursos que não estão disponíveis na edição de nível inferior.

Para restaurar um backup para uma instância com uma configuração de instância diferente ou em um projeto diferente, primeiro copie o backup para a região ou projeto de destino.

Por exemplo, se você tiver um backup em uma instância que usa a configuração us-west3, poderá restaurar o backup para qualquer instância no projeto que também use a configuração us-west3. No entanto, para restaurar esse backup para uma instância que usa a configuração us-east1 ou para uma instância em um projeto diferente, primeiro copie o backup para uma instância na região ou projeto de destino e, em seguida, restaure o backup copiado.

O processo de restauração foi projetado para alta disponibilidade. É possível restaurar o banco de dados desde que a maioria das regiões e zonas na instância de destino esteja disponível.

Para restaurar um backup ativado com chaves de criptografia gerenciadas pelo cliente (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.

É possível restaurar um banco de dados para uma edição de nível inferior somente quando o banco de dados usa recursos disponíveis nessa edição de nível inferior. Por exemplo, se o banco de dados usar o particionamento geográfico, restaure o banco de dados para uma instância que use a edição Enterprise Plus.

Restaurar um backup para uma região ou projeto diferente

Se você precisar restaurar o backup para uma região ou projeto diferente, primeiro, copie o backup para a região ou projeto escolhido. É possível restaurar o backup copiado assim que a cópia for concluída. Antes de restaurar, verifique se a instância de destino tem nós ou unidades de processamento provisionados suficientes para oferecer suporte ao tamanho do banco de dados de acordo com o limite de armazenamento de 10 TB por nó. Por exemplo, 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, 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 montando arquivos do backup. Durante esse estado CREATING inicial, o banco de dados restaurado ainda não está pronto para uso. Esse estado normalmente é concluído em uma hora. Quando o estado CREATING é concluído, o banco de dados está 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 RestoreDatabaseMetadata objeto.

    Confira as seguintes advertências sobre o estado CREATING:

    • Se você estiver restaurando para uma instância diferente, a operação de restauração pertence à 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 excluí-lo 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 estado READY_OPTIMIZING ou READY.

  • READY_OPTIMIZING: depois que o Spanner monta o backup, ele começa a copiar os dados de backup para o novo banco de dados enquanto otimiza o tamanho armazenado. O 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 de tamanho.

    Embora seja possível usar o banco de dados normalmente durante READY_OPTIMIZING, as seguintes advertências se aplicam:

    • As latências de leitura podem ser um pouco maiores do que o normal.
    • As métricas de armazenamento mostram o tamanho de o novo banco de dados, não o 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 dados.
    • Assim como no estado CREATING, o Spanner não permite excluir o backup montado.

    O Spanner disponibiliza outra operação de restauração de longa duração disponível durante esse estado, desta vez retornando um objeto de metadados OptimizeRestoredDatabaseMetadata.

  • READY: quando a operação de cópia e otimização é concluída, o banco de dados faz a transição para o estado READY. O banco de dados é totalmente restaurado e não faz mais referência nem exige o backup.

Controle de acesso (IAM)

O papel 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. Esse papel 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 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