Como restaurar bancos de dados e tabelas para um ponto no tempo - PolarDB: Central de Documentação do Alibaba Cloud

Pré-requisitos

Um conjunto de backup deve estar disponível. A PITR restaura um backup completo criado antes do momento selecionado e aplica dados incrementais dos redo logs até atingir esse ponto no tempo.
Para reduzir o tempo de recuperação, ative o backup aprimorado. Esse recurso encurta o ciclo de backup e aumenta sua densidade, o que diminui o volume de redo logs a reproduzir.

Edições e versões compatíveis

A restauração de bancos de dados e tabelas é compatível com as edições Enterprise Edition (Cluster Edition) e Standard Edition do PolarDB. Cada edição exige uma versão mínima de revisão do cluster.

Dois níveis de revisão se aplicam:

Recursos básicos: Versão mínima de revisão necessária para a restauração de bancos de dados e tabelas.
Cluster primário GDN / Novo processo de restauração: Versão mínima de revisão para utilizar este recurso em um cluster primário da global database network (GDN), ou para usar o novo processo de restauração que otimiza a velocidade de restauração.

Nota

O novo processo de restauração otimiza a velocidade de recuperação de dados para o cluster original. Para obter detalhes sobre o mecanismo e o tempo estimado, consulte

Fluxo geral e tempo estimado

.

Enterprise Edition (Cluster Edition)

Versão do MySQL	Arquitetura	Recursos básicos (revisão mín.)	Cluster primário GDN / Novo processo de restauração (revisão mín.)
5,6	x86	`5.6.1.0.25`	`5.6.1.0.42`
5,7	x86	`5.7.1.0.8`	`5.7.1.0.36`
8,0.1	x86	`8.0.1.1.14`	`8.0.1.1.46`
8,0.2	x86	`8.0.2.2.0`	`8.0.2.2.26`

Standard Edition

Versão do MySQL	Arquitetura	Recursos básicos (revisão mín.)	Cluster primário GDN / Novo processo de restauração (revisão mín.)
5,6	x86	`5.6.1.0.42`	`5.6.1.0.42`
5,7	x86	`5.7.1.0.30`	`5.7.1.0.30`
8,0.1	x86	`8.0.1.1.38.2`	`8.0.1.1.38.2`
8,0.1	Yitian (ARM)	`8.0.1.1.41`	`8.0.1.1.41`
8,0.2	x86	`8.0.2.2.21`	`8.0.2.2.21`

Nota

Para verificar a versão do kernel do seu cluster, acesse a seção

Configuration Information

na página

Basic Information

do seu cluster PolarDB for MySQL.

Limitações

Categoria	Limitação
Tipo de cluster	Não há suporte para clusters da Multi-master Cluster (Limitless) Edition.
Tipo de cluster	Não há suporte para clusters secundários em uma global database network (GDN).
Tipo de cluster	Clusters com mais de 50.000 tabelas não são suportados quando o tipo de armazenamento é enterprise SSD (ESSD) ou quando o cluster não possui nós somente leitura (RO).
Esquema da tabela	Não é possível restaurar tabelas que contêm um global secondary index (GSI).
Índice	Dados do In-Memory Column Index (IMCI) (índices columnstore) não são restaurados.
Mecanismo de armazenamento	Apenas tabelas que utilizam o mecanismo de armazenamento InnoDB podem ser restauradas.
Status dos dados	Não é possível restaurar tabelas arquivadas como cold data.

Nota

Caso seu cluster não ofereça suporte à restauração de bancos de dados e tabelas, utilize a

restauração completa

para recuperar os dados em um novo cluster e, em seguida,

migre os dados

de volta para o cluster de origem.

Observações de uso

Após a conclusão da PITR, os dados nas tabelas restauradas correspondem exatamente aos dados do momento especificado.
A restauração é permitida apenas a partir de backups de nível 1; backups de nível 2 não são suportados.
Somente as tabelas selecionadas serão restauradas. Certifique-se de selecionar todas as tabelas necessárias.
Este recurso funciona mesmo se o cluster contiver mais de 50.000 tabelas, incluindo tabelas de sistema.
Ao restaurar tabelas individuais em vez de um banco de dados inteiro, o limite é de até 100 tabelas por vez. Na restauração de um banco de dados completo, todas as tabelas desse banco são recuperadas.
Triggers não são restauradas.
Foreign keys não são restauradas.
Execute a restauração fora dos horários de pico para minimizar o impacto nas cargas de trabalho em execução.

Nota

Se você não tiver certeza sobre quais tabelas restaurar ou precisar recuperar mais de 100 tabelas, realize uma restauração completa do cluster.

Etapa 1: Identificar o ponto no tempo

Caso já saiba quando ocorreu a modificação ou exclusão acidental de dados, pule para a Etapa 2.

Utilize um dos métodos abaixo para encontrar o momento exato.

Método 1: SQL Explorer

Se o recurso SQL Explorer do PolarDB for MySQL Cluster Edition estiver ativado, consulte os logs de auditoria para identificar quando a operação acidental ocorreu.

Nota

O SQL Explorer é um serviço pago. A cobrança refere-se ao espaço de armazenamento ocupado pelos logs de auditoria, conforme o período de retenção configurado. Para mais informações, consulte

SQL Explorer

. O SQL Explorer registra apenas logs SQL gerados após sua ativação. Se o recurso não estava habilitado no momento do incidente, utilize o Método 2.

Método 2: Analisar binary logs

Ative o log binário. Para mais informações, consulte Enable binary logging.

Nota
O log binário deve estar ativado para que seja possível visualizar ou recuperar binary logs. Caso contrário, a mensagem de erro

You are not using binary logging

será retornada.
Instale o MySQL no servidor local e conecte-se ao cluster pelo cliente MySQL. Para detalhes, consulte Connect to a cluster. Os exemplos a seguir utilizam um sistema operacional Linux.

Execute o comando abaixo no cliente conectado para visualizar os binary logs disponíveis: Exemplo de saída:

   show binary logs;

   +------------------+-----------+
   | Log_name         | File_size |
   +------------------+-----------+
   | mysql-bin.000005 |      2639 |
   +------------------+-----------+
   1 row in set (0.00 sec)

Saia do MySQL e execute o seguinte comando para baixar os binary logs para o servidor local: Exemplo:

Nota

Se o endpoint utilizar a porta padrão 3306, não é necessário especificar o número da porta. Caso contrário, anexe o número da porta ao endpoint. - A conexão remota para recuperação de binary logs só é possível por endpoints públicos do endpoint primário ou endpoints de cluster (padrão ou personalizados). Para informações sobre como solicitar um endpoint público, consulte

Manage the endpoints of a cluster

.

Parâmetro	Descrição	Exemplo
`-u`	Nome da conta do seu cluster.	`test_api`
`-p`	Senha da sua conta. Se omitida, o sistema solicitará a senha após a execução do comando.	`TestPwd123`
`-h`	Endpoint público do seu cluster.	`test-polardb.rwlb.rds.aliyuncs.com`
`--raw`	Gera saída dos binary logs em formato bruto, sem análise.	`--raw`
`mysql-bin.******`	Nome do binary log obtido no campo `Log_name` da saída do comando `show binary logs;`.	`mysql-bin.000005`

   mysqlbinlog -u <username> -p <password> -h <endpoint> --read-from-remote-server --raw mysql-bin.******

   mysqlbinlog -utest_api -p -htest-polardb.rwlb.rds.aliyuncs.com --read-from-remote-server --raw mysql-bin.000005

Download binary logs

Execute o comando a seguir para visualizar detalhes do binary log: A figura abaixo mostra um exemplo de saída de binary log.

Nota
-

-vv

: Exibe instruções SQL e comentários. -

--base64-output=decode-rows

: Converte entradas do binary log em um formato legível.
```
   mysqlbinlog -vv --base64-output=decode-rows mysql-bin.****** | more
```
Após obter os arquivos de binary log, consulte mysqlbinlog - Utility for Processing Binary Log Files para ver todas as opções de análise.

Etapa 2: Restaurar bancos de dados e tabelas

Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters. Selecione a Region onde o cluster está implantado e clique no ID do cluster.
No painel de navegação à esquerda, escolha Settings and Management > Backup and Restoration e clique em Restore Databases/Tables.
Na caixa de diálogo, defina Restoration Type como Point in Time e configure Restoration Time para o momento desejado.

Nota
O valor de

Restoration Time

deve estar dentro do intervalo exibido em

Restore To

. O intervalo disponível depende do parâmetro

Log Retention Period (Days)

, cujo padrão é sete dias. O conjunto de backup completo mais próximo do momento especificado deve conter as tabelas que você deseja restaurar.

Escolha uma velocidade de restauração conforme sua necessidade. Cada opção consome uma porcentagem diferente de operações de entrada/saída por segundo (IOPS) no cluster atual. Para estimativas de duração da restauração, consulte Reference test data for database and table restoration speed.

Velocidade	Consumo de IOPS	Orientação
Quick	~60%	Recomendado para horários fora de pico.
Standard (recomendado)	~30%	Opção equilibrada para a maioria das cargas de trabalho.
Secure	~15%	Impacto mínimo, mas significativamente mais lento.

Na seção Databases and Tables to Restore, selecione o banco de dados alvo no lado esquerdo e marque as tabelas a serem restauradas no lado direito.
Nota
- Se nenhum nome for especificado para o banco de dados ou tabela de destino, o sistema adicionará o sufixo
_backup

ao nome original. Por exemplo, uma tabela chamada

test

será restaurada como

test_backup

. - Ao selecionar um banco de dados sem escolher tabelas específicas, todas as tabelas desse banco serão restauradas.
Verifique se os bancos de dados e tabelas selecionados estão corretos e clique em OK.

Etapa 3: Verificar dados restaurados

Após a conclusão da restauração, faça login no cluster para comparar os dados recuperados com os originais.

Conecte-se pelo Data Management Service (DMS), cliente MySQL ou linha de comando. Os passos abaixo utilizam o DMS. Para outros métodos, consulte Conectar-se a um cluster de banco de dados.

Na página Basic Information do seu cluster, clique em Log on to Database no canto superior direito.
Insira a Database Account e a Database Password e clique em Log On.
Após fazer login no DMS, atualize a página. No painel de navegação à esquerda, clique em Logged-in Instance.
Na lista Logged-in Instance, clique no nome do cluster e dê um clique duplo no banco de dados alvo.
Localize os dados afetados pela operação acidental. Confirme se os dados restaurados correspondem ao estado esperado antes da operação e se os demais dados permanecem consistentes.