Esta página descreve como usar a recuperação num ponto específico no tempo (PITR) para reter e recuperar dados no Spanner para bases de dados com dialeto GoogleSQL e bases de dados com dialeto PostgreSQL.
Para saber mais, consulte o artigo Recuperação num ponto específico no tempo.
Pré-requisitos
Este guia usa a base de dados e o esquema conforme definidos no início rápido do Spanner. Pode executar o início rápido para criar a base de dados e o esquema, ou modificar os comandos para utilização com a sua própria base de dados.
Defina o período de retenção
Para definir o período de retenção da base de dados:
Consola
Aceda à página Instâncias do Spanner na Google Cloud consola.
Clique na instância que contém a base de dados para abrir a respetiva página Vista geral.
Clique na base de dados para abrir a respetiva página Vista geral.
Selecione o separador Cópia de segurança/restauro.
Clique no ícone de lápis no campo Período de retenção de versões.
Introduza uma quantidade e uma unidade de tempo para o período de retenção e, de seguida, clique em Atualizar.
gcloud
Atualize o esquema da base de dados com a declaração ALTER DATABASE. Por exemplo:
gcloud spanner databases ddl update example-db \
--instance=test-instance \
--ddl='ALTER DATABASE `example-db` \
SET OPTIONS (version_retention_period="7d");'
Para ver o período de retenção, obtenha o DDL da sua base de dados:
gcloud spanner databases ddl describe example-db \
--instance=test-instance
Segue-se o resultado:
ALTER DATABASE example-db SET OPTIONS (
version_retention_period = '7d'
);
...
Bibliotecas cliente
C#
C++
Go
Java
Node.js
PHP
Python
Ruby
Notas de utilização:
- O período de retenção tem de ser entre 1 hora e 7 dias e pode ser especificado em dias, horas, minutos ou segundos. Por exemplo, os valores
1d
,24h
,1440m
e86400s
são equivalentes. - Se tiver ativado o registo para a API Spanner no seu projeto, o evento é registado como UpdateDatabaseDdl e é visível no Explorador de registos.
- Para reverter para o período de retenção predefinido de 1 hora, pode definir a opção de base de dados
version_retention_period
comoNULL
para bases de dados GoogleSQL ouDEFAULT
para bases de dados PostgreSQL. - Quando prolonga o período de retenção, o sistema não preenche versões anteriores dos dados. Por exemplo, se prolongar o período de retenção de uma hora para 24 horas, tem de aguardar 23 horas para que o sistema acumule dados antigos antes de poder recuperar dados de 24 horas atrás.
Obtenha o período de retenção e a hora da versão mais antiga
O recurso Database inclui dois campos:
version_retention_period
: o período durante o qual o Spanner retém todas as versões dos dados da base de dados.earliest_version_time
: a data/hora mais antiga em que as versões anteriores dos dados podem ser lidas a partir da base de dados. Este valor é atualizado continuamente pelo Spanner e fica desatualizado no momento em que é consultado. Se estiver a usar este valor para recuperar dados, certifique-se de que tem em conta o tempo desde o momento em que o valor é consultado até ao momento em que inicia a recuperação.
Consola
Aceda à página Instâncias do Spanner na Google Cloud consola.
Clique na instância que contém a base de dados para abrir a respetiva página Vista geral.
Clique na base de dados para abrir a respetiva página Vista geral.
Selecione o separador Cópia de segurança/restauro para abrir a página Cópia de segurança/restauro e apresentar o período de retenção.
Clique em Criar para abrir a página Criar uma cópia de segurança e apresentar a hora da versão mais antiga.
gcloud
Pode obter estes campos chamando describe databases ou list databases. Por exemplo:
gcloud spanner databases describe example-db \
--instance=test-instance
Segue-se o resultado:
createTime: '2020-09-07T16:56:08.285140Z'
earliestVersionTime: '2020-10-07T16:56:08.285140Z'
name: projects/my-project/instances/test-instance/databases/example-db
state: READY
versionRetentionPeriod: 3d
Recupere uma parte da sua base de dados
Efetue uma leitura desatualizada e especifique a data/hora de recuperação necessária. Certifique-se de que a indicação de tempo especificada é mais recente do que a indicação de tempo
earliest_version_time.
gcloud
Use execute-sql Por exemplo:
gcloud spanner databases execute-sql example-db \ --instance=test-instance --read-timestamp=2020-09-11T10:19:36.010459-07:00\ --sql='SELECT * FROM SINGERS'
Bibliotecas cliente
Consulte realizar leitura desatualizada.
Armazenar os resultados da consulta. Isto é necessário porque não pode escrever os resultados da consulta novamente na base de dados na mesma transação. Para pequenas quantidades de dados, pode imprimir na consola ou armazenar na memória. Para quantidades maiores de dados, pode ter de escrever num ficheiro local.
Escreva os dados recuperados novamente na tabela que precisa de ser recuperada. Por exemplo:
gcloud
gcloud spanner rows update --instance=test-instance --database=example-db --table=Singers \ --data=SingerId=1,FirstName='Marc'
Para mais informações, consulte o artigo sobre atualizar dados com o gcloud.
Bibliotecas cliente
Para mais informações, consulte os artigos sobre atualizar dados através de DML ou atualizar dados através de mutações.
Opcionalmente, se quiser fazer alguma análise dos dados recuperados antes de os escrever novamente, pode criar manualmente uma tabela temporária na mesma base de dados, escrever primeiro os dados recuperados nesta tabela temporária, fazer a análise e, em seguida, ler os dados que quer recuperar desta tabela temporária e escrevê-los na tabela que precisa de ser recuperada.
Recupere uma base de dados completa
Pode recuperar toda a base de dados através da opção Cópia de segurança e restauro ou Importar e exportar e especificar uma data/hora de recuperação.
Cópia de segurança e restauro
Crie uma cópia de segurança e defina o
version_time
para a data/hora de recuperação necessária.Consola
Aceda à página Detalhes da base de dados na Cloud Console.
No separador Cópia de segurança/restauro, clique em Criar.
Selecione a caixa Criar cópia de segurança a partir de um ponto anterior no tempo.
gcloud
gcloud spanner backups create example-db-backup-1 \ --instance=test-instance \ --database=example-db \ --retention-period=1y \ --version-time=2021-01-22T01:10:35Z --async
Para mais informações, consulte o artigo Crie uma cópia de segurança com o gcloud.
Bibliotecas cliente
C#
C++
Go
Java
Node.js
PHP
Python
Ruby
Restaure a partir da cópia de segurança para uma nova base de dados. Tenha em atenção que o Spanner preserva a definição do período de retenção da cópia de segurança para a base de dados restaurada.
Consola
Aceda à página Detalhes da instância na Cloud Console.
No separador Cópia de segurança/restauro, selecione uma cópia de segurança e clique em Restaurar.
gcloud
gcloud spanner databases restore --async \ --destination-instance=destination-instance --destination-database=example-db-restored \ --source-instance=test-instance --source-backup=example-db-backup-1
Para mais informações, consulte o artigo Restaurar uma base de dados a partir de uma cópia de segurança.
Bibliotecas cliente
C#
C++
Go
Java
Node.js
PHP
Python
Ruby
Importação e exportação
- Exporte a base de dados, especificando o parâmetro
snapshotTime
para a data/hora de recuperação necessária.Consola
Aceda à página Detalhes da instância na Cloud Console.
No separador Importar/Exportar, clique em Exportar.
Selecione a caixa Exportar base de dados de um momento anterior.
Para ver instruções detalhadas, consulte o artigo sobre como exportar uma base de dados.
gcloud
Use o modelo do Dataflow Spanner para Avro para exportar a base de dados.
gcloud dataflow jobs run JOB_NAME \ --gcs-location='gs://cloud-spanner-point-in-time-recovery/Import Export Template/export/templates/Cloud_Spanner_to_GCS_Avro' --region=DATAFLOW_REGION \ --parameters='instanceId=test-instance,databaseId=example-db,outputDir=YOUR_GCS_DIRECTORY,snapshotTime=2020-09-01T23:59:40.125245Z'
Notas de utilização:
- Pode acompanhar o progresso das suas tarefas de importação e exportação na consola do Dataflow.
- O Spanner garante que os dados exportados são externa e transacionalmente consistentes na data/hora especificada.
- Especifique a data/hora no formato RFC 3339. Por exemplo, 2020-09-01T23:59:30.234233Z.
- Certifique-se de que a data/hora especificada é mais recente do que a data/hora de atualização da base de dados
earliest_version_time
. Se os dados já não existirem na data/hora especificada, recebe um erro.
Importar para uma nova base de dados.
Consola
Aceda à página Detalhes da instância na Cloud Console.
No separador Importar/exportar, clique em Importar.
Para ver instruções detalhadas, consulte o artigo Importar ficheiros Avro do Spanner.
gcloud
Use o modelo do Dataflow Cloud Storage Avro to Spanner para importar os ficheiros Avro.
gcloud dataflow jobs run JOB_NAME \ --gcs-location='gs://cloud-spanner-point-in-time-recovery/Import Export Template/import/templates/GCS_Avro_to_Cloud_Spanner' \ --region=DATAFLOW_REGION \ --staging-location=YOUR_GCS_STAGING_LOCATION \ --parameters='instanceId=test-instance,databaseId=example-db,inputDir=YOUR_GCS_DIRECTORY'
Estime o aumento do armazenamento
Antes de aumentar o período de retenção de versões de uma base de dados, pode estimar o aumento esperado na utilização do armazenamento da base de dados totalizando os bytes de transação durante o período necessário. Por exemplo, a seguinte consulta calcula o número de GiB escritos nos últimos 7 dias (168 horas) lendo a partir das tabelas de estatísticas de transações.
GoogleSQL
SELECT
SUM(bytes_per_hour) / (1024 * 1024 * 1024 ) as GiB
FROM (
SELECT
((commit_attempt_count - commit_failed_precondition_count - commit_abort_count) * avg_bytes)
AS bytes_per_hour, interval_end
FROM
spanner_sys.txn_stats_total_hour
ORDER BY
interval_end DESC
LIMIT
168);
PostgreSQL
SELECT
bph / (1024 * 1024 * 1024 ) as GiB
FROM (
SELECT
SUM(bytes_per_hour) as bph
FROM (
SELECT
((commit_attempt_count - commit_failed_precondition_count - commit_abort_count) * avg_bytes)
AS bytes_per_hour, interval_end
FROM
spanner_sys.txn_stats_total_hour
ORDER BY
interval_end DESC
LIMIT
168)
sub1) sub2;
Tenha em atenção que a consulta fornece uma estimativa aproximada e pode ser imprecisa por alguns motivos:
- A consulta não tem em conta a data/hora que tem de ser armazenada para cada versão dos dados antigos. Se a sua base de dados consistir em muitos tipos de dados pequenos, a consulta pode subestimar o aumento do armazenamento.
- A consulta inclui todas as operações de escrita, mas apenas as operações de atualização criam versões anteriores dos dados. Se a sua carga de trabalho incluir muitas operações de inserção, a consulta pode sobrestimar o aumento do armazenamento.