PolarDB:Restauração de banco de dados e tabela: Recuperação point-in-time

Pré-requisitos

É necessário ter um conjunto de backup disponível. A recuperação point-in-time primeiro restaura no cluster um backup completo de dados obtido antes do ponto no tempo selecionado. Em seguida, utiliza redo logs para restaurar dados incrementais até o ponto no tempo escolhido. Para aumentar a velocidade de restauração, ative o backup aprimorado, que reduz o ciclo de backup e aumenta a densidade dos backups.

Cenários

Observações de uso

• A restauração point-in-time consiste em selecionar um momento específico para recuperar tabelas de banco de dados. Após a restauração, as tabelas conterão apenas os dados correspondentes àquele exato momento. Ou seja, os dados da tabela no banco de dados estarão consistentes com o estado daquele ponto no tempo.

• Atualmente, o método "Restaurar para um ponto no tempo passado" da restauração de banco de dados e tabela suporta apenas a recuperação a partir de um ponto no tempo de um backup de nível 1. Não há suporte para restauração a partir de um backup de nível 2.

• A restauração de banco de dados e tabela falha nos seguintes cenários:

  • O nome do banco de dados ou da tabela especificado já existe no cluster original.

  • Entre o momento em que o conjunto de backup foi gerado e o ponto no tempo da restauração, a tabela a ser restaurada foi excluída, ou o cluster contém um banco de dados ou tabela com o mesmo nome do banco de dados ou tabela de destino.

• A restauração de banco de dados e tabela recupera apenas as tabelas especificadas. Certifique-se de selecionar todas as tabelas que deseja restaurar.

  Nota

  Caso não consiga determinar todas as tabelas envolvidas, restaure os dados históricos de todo o cluster para um novo cluster e migre os dados de volta para o cluster original. Para obter mais informações, consulte Restore from a backup set e Restore a cluster to a point in time.

• Se você não restaurar um banco de dados inteiro, será possível restaurar até 100 tabelas desse banco de dados por vez. Ao restaurar um banco de dados completo, todas as tabelas nele contidas serão recuperadas.

  Nota

  • Restaurar muitas tabelas simultaneamente demanda bastante tempo; portanto, evite restaurar um volume excessivo de tabelas de uma só vez.

  • Quando for necessário restaurar uma grande quantidade de tabelas, prefira restaurar todos os dados históricos para um novo cluster. Para etapas detalhadas, consulte Restore from a backup set e Restore a cluster to a point in time.

• É possível utilizar a restauração de banco de dados e tabela mesmo quando o cluster contém mais de 50.000 tabelas, incluindo tabelas de sistema.

  Nota

  • Este recurso está atualmente em lançamento canary. Para utilizá-lo, Contact us: entre na lista de permissões e ative o recurso.

  • Consulte o número de tabelas, incluindo as de sistema, no cluster. Execute a seguinte instrução SQL:

    SELECT COUNT(*) FROM information_schema.tables;

  • Verifique a quantidade de tabelas de sistema no cluster executando a seguinte instrução SQL:

    SELECT COUNT(*) FROM information_schema.tables WHERE table_schema IN ('sys', 'performance_schema', 'mysql', 'information_schema', '__recycle_bin__');

• A restauração de banco de dados e tabela não oferece suporte à recuperação de triggers. Se a tabela original possuir um trigger, ele não será restaurado.

• Não há suporte para restauração de chaves estrangeiras na recuperação de banco de dados e tabela. Caso a tabela original tenha uma chave estrangeira, ela não será restaurada.

• Restaure os dados durante horários de baixa demanda.

Etapa 1: Identificar o horário da operação incorreta

Caso já saiba o momento em que a operação acidental ocorreu, pule esta etapa. Se não tiver certeza do horário exato, siga estas instruções para determiná-lo.

Método 1: SQL Explorer

Se você ativou o SQL Explorer para o seu cluster PolarDB for MySQL Cluster Edition, utilize esse recurso para visualizar o log de auditoria e identificar o horário da operação acidental.

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

Método 2: Buscar e analisar binary logs remotamente

1. Ative o binary logging para o cluster. Para instruções detalhadas, consulte Enable binary logging.

   Nota

   É obrigatório ativar o binary logging no cluster antes de visualizar e buscar o binary log. Caso contrário, será retornado o erro You are not using binary logging.

2. Instale o MySQL no servidor local e conecte-se ao cluster usando um cliente MySQL. Para instruções detalhadas, consulte Connect to a database cluster. Este tópico usa um sistema Linux como exemplo.

   root@xxx:~# mysql -h xxx-polardb.rwlb.rds.aliyuncs.com -P3306 -utest_api -p
   Enter password:
   Welcome to the MySQL monitor.  Commands end with ; or \g.
   Your MySQL connection id is xxx
   Server version: 8.0.13 Source distribution
   Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
   Oracle is a registered trademark of Oracle Corporation and/or its
   affiliates.  Other names may be trademarks of their respective
   owners.
   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
   mysql>

3. No cliente MySQL conectado, execute o comando a seguir para visualizar a lista de arquivos de binary log do cluster de destino:

   show binary logs;

   O comando retorna a seguinte saída:

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

4. Busque o binary log remotamente e salve-o na máquina local.

   Este tópico usa um sistema Linux como exemplo. Primeiro, execute exit para sair do cliente MySQL. Em seguida, execute o comando a seguir para buscar o binary log.

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

   Parâmetro	Descrição	Exemplo
   -u	Nome de usuário da conta do banco de dados no cluster.	test_api
   -p	Senha da conta. Se deixada em branco, o sistema solicitará que você a insira após a execução do comando.	TestPwd123
   -h	Endpoint público do cluster. Nota Se o endpoint do cluster utilizar a porta padrão 3306, omita o número da porta. Caso contrário, anexe o número da porta ao endpoint. Atualmente, a busca remota do binary log só é possível através do endpoint público do nó primário ou de um endpoint de cluster (incluindo endpoints de cluster padrão e personalizados). Para saber como solicitar um endpoint público, consulte Manage endpoints.	test-polardb.rwlb.rds.aliyuncs.com
   --read-from-remote-server	Indica que o binary log é lido diretamente do servidor MySQL, e não de um arquivo de log local.	--read-from-remote-server
   --raw	Especifica que o arquivo de binary log buscado será impresso em seu formato original, em vez de dados analisados.	--raw
   mysql-bin.	Nome do arquivo de binary log de destino, conforme listado na coluna Log_name do comando show binary logs;.	mysql-bin.000005

   Exemplo:

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

5. Execute o comando a seguir para visualizar o conteúdo do arquivo de binary log usando a ferramenta mysqlbinlog:

   mysqlbinlog -vv --base64-output=decode-rows mysql-bin.****** | more

   Nota

   • -vv: Exibe instruções SQL específicas e comentários.

   • --base64-output=decode-rows: Analisa o arquivo de binary log.

   A saída será semelhante à seguinte:

   [root@iZxxx ~]# mysqlbinlog -vv --base64-output=decode-rows mysql-bin.000110 | more
   /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
   /*!40019 SET @@session.max_insert_delayed_threads=0*/;
   /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
   DELIMITER /*!*/;
   # at 4
   #160217 23:04:37 server id 2802943055  end_log_pos 107  Start: binlog v 4, server v 5.5.18.1-log created 160217 23:04:37
   # at 107
   #160217 23:04:38 server id 2802943055  end_log_pos 171  Query    thread id=584632    exec time=0    error code=0
   SET TIMESTAMP=1xxx8/*!*/;
   SET @@session.pseudo_thread_id=584632/*!*/;
   SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
   SET @@session.sql_mode=2097152/*!*/;
   SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
   /*!\C utf8 *//*!*/;
   SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
   SET @@session.lc_time_names=0/*!*/;
   SET @@session.collation_database=DEFAULT/*!*/;
   BEGIN
   /*!*/;
   # at 171

6. Após recuperar o conteúdo do arquivo de binary log, você pode parse the binary log.

Etapa 2: Iniciar a restauração de banco de dados e tabela

1. 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 para acessar a página de detalhes do cluster.

2. No painel de navegação à esquerda, escolha Settings and Management > Backup and Restoration e clique em Restore Databases/Tables.

3. Na caixa de diálogo exibida, defina Restoration Type como Point in Time e selecione o ponto no tempo desejado em Restoration Time.

   Nota

   • O Restoration Time deve estar dentro do intervalo especificado por Restore To. Além disso, o backup completo mais próximo do ponto no tempo selecionado deve conter a tabela a ser restaurada para que a recuperação Point in Time funcione corretamente. O intervalo de pontos no tempo recuperáveis depende do período de retenção especificado em Log Retention Period (Days) nas configurações de backup. O valor padrão é 7 dias.

   • Com base no consumo de IOPS, a restauração de banco de dados e tabela oferece três configurações de velocidade: Quick, Standard e Secure. Escolha uma configuração conforme suas necessidades. Para o tempo estimado de cada configuração de velocidade de restauração, consulte Reference test data for database and table restoration speed.

     • Quick: A restauração de dados no cluster atual pode consumir uma grande quantidade de IOPS. Escolha esta configuração durante horários de baixa demanda.

     • Standard (recomendado para especificações com mais de 4 núcleos): A restauração de dados no cluster atual pode consumir parte dos IOPS disponíveis.

     • Secure (recomendado para especificações com 4 núcleos ou menos): A restauração de dados no cluster atual consome apenas uma pequena quantidade de IOPS, mas pode reduzir significativamente a velocidade de restauração.

     Para clusters com especificações de 4 núcleos ou menos, certifique-se de que as configurações de innodb_io_capacity e innodb_io_capacity_max correspondam às especificações. Para especificações de cluster e IOPS máximo suportado, consulte Compute node specifications for Enterprise Edition e Compute node specifications for Standard Edition, e utilize a velocidade de restauração Secure.

4. No lado esquerdo da seção Databases and Tables to Restore, selecione o banco de dados de destino que deseja restaurar e, no lado direito, selecione as tabelas de destino.

   Nota

   • Se você não especificar novos nomes de banco de dados ou tabela, o sistema os gera automaticamente adicionando _backup ao nome original do banco de dados ou da tabela. Por exemplo, se a tabela original for test, o nome da tabela gerado automaticamente será test_backup.

   • Ao selecionar um banco de dados de destino sem especificar tabelas, todos os dados do banco de dados são restaurados por padrão.

5. Após confirmar que os bancos de dados e tabelas que deseja restaurar estão selecionados, clique em OK.

Etapa 3: Comparar dados

Após a conclusão da restauração de banco de dados e tabela, faça login no cluster para comparar e verificar os dados.

O acesso ao cluster pode ser feito via Data Management Service (DMS), outro cliente ou linha de comando. Este tópico descreve como fazer login no cluster usando o DMS para verificar os dados. Para informações sobre outros métodos, consulte Connect to a cluster.

1. No canto superior direito da página Basic Information do cluster, clique em Log on to Database.

2. Na caixa de diálogo exibida, insira a Database Account e a Database Password do cluster e clique em Search.

3. Após fazer login no DMS, atualize a página. No painel de navegação à esquerda, clique em Logged in instance.

4. Na lista Logged in instance, clique no nome do cluster de destino e localize e clique duas vezes no nome do banco de dados de destino para alternar para o gerenciamento desse banco de dados.

5. Localize os dados afetados pela operação acidental. Verifique se os dados foram restaurados ao estado anterior à operação e se outros dados também correspondem a esse estado.