Visão geral da restauração

É possível restaurar um backup de um banco de dados do Spanner em um novo banco de dados. O o banco de dados restaurado terá todos os dados e o esquema do banco de dados original em version_time do backup, incluindo todas as opções de banco de dados definidas pelo ALTER DATABASE SET OPTIONS kubectl. Ele não terá permissões do IAM (exceto as herdadas da instância que contém o banco de dados restaurado), e você precisará aplicar as permissões apropriadas do IAM após a conclusão da restauração. Ele não vai incluir os dados internos de fluxo de alterações. Ao restaurar de um backup, o backup restaurado reside na mesma instância, região projeto como 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 a partir do backup copiado.

A restauração de um backup pode ser usada das seguintes maneiras:

Como funciona a restauração do banco de dados a partir de um backup

Ao restaurar um banco de dados do Spanner, especifique uma origem e um novo banco de dados de destino. Não é possível restaurar para um banco de dados atual. O banco de dados 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 (ou de nível superior) edição do Spanner 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 em 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 restauradas desde que a maioria do quórum das regiões e zonas na instância estiver 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 a mesma configurações de criptografia como 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 uma região ou um projeto diferente

Se você precisar restaurar o backup para uma região ou um projeto diferente, primeiro copie o backup para a da região ou do projeto escolhido. Os backups copiados podem ser restaurados assim que a cópia termina. É possível restaurar o backup na instância de destino (contanto que já que usa a edição como a instância de backup de origem) ou em qualquer instância que tem a mesma configuração de instância e edição (ou de nível superior) que o instância de destino. 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 10 TB por armazenamento de 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 e, se quiser restaurá-lo ali, o nome de destino tem cotas de nós suficientes para a restauração. Como restaurar uma cópia 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 inicial de CREATING, o banco de dados restaurado ainda não está pronto para uso. Esse estado geralmente é concluído em uma hora. Quando o estado CREATING for concluído, o banco de dados estará pronto para uso.

    Para acompanhar o progresso desse estado, é possível consultar a restauração de longa duração operação que O Spanner é disponibilizado 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 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 que você exclua o backup enquanto ele está sendo restaurado. Você pode 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 a restauração com base nos backups. Não será possível restaurar outro backup 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 do backup para o novo banco de dados, otimizando o tamanho armazenado. Seu banco de dados está pronto para ser usado 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, a as seguintes advertências se aplicam:

    • As latências de leitura podem ser um pouco mais altas 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 reflitam o tamanho total de todos os dados.
    • Assim como no estado CREATING, o Spanner não vai permitir que você exclua o backup montado.

    O Spanner faz outra operação de restauração de longa duração disponível durante esse estado, dessa vez retornando um 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 estado READY. O banco de dados é totalmente restaurado, e nenhuma referências mais longas ou que exigem 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 e restauração. Esse papel não pode criar, atualizar, excluir nem copiar um backup.

Preços

Não há cobrança pela restauração de um backup.

A seguir