ApsaraDB RDS:Flashback natif

Présentation

Les erreurs humaines lors de la maintenance de la base de données peuvent avoir un impact sévère sur votre activité. Les méthodes de récupération traditionnelles, telles que le flashback Binlog, sont complexes, sujettes aux erreurs et chronophages. La restauration à partir d'un jeu de sauvegarde nécessite des ressources système supplémentaires et le temps de récupération devient imprévisible pour les volumes de données importants.

AliSQL introduit le flashback natif pour le moteur InnoDB, éliminant ainsi les opérations de récupération complexes. Grâce à de simples instructions SQL, vous pouvez interroger ou restaurer les données historiques antérieures à une opération accidentelle, réduisant le temps de récupération et minimisant l'impact sur l'activité.

Prérequis

Votre instance doit exécuter l'une des versions de base de données suivantes. Si la version mineure du moteur ne répond pas aux exigences, vous pouvez la mettre à jour.

• MySQL 8.4

• MySQL 8.0 avec une version mineure du moteur égale ou supérieure à 20210930.

Limites

• Seules les tables utilisant le moteur InnoDB sont prises en charge.

• Cette fonctionnalité consomme de l'espace dans le tablespace undo supplémentaire. Vous pouvez limiter la taille maximale à l'aide du paramètre innodb_undo_space_supremum_size.

• Une requête de flashback natif renvoie les données correspondant à l'instant le plus proche de l'horodatage spécifié. Une correspondance exacte n'est pas garantie.

• L'interrogation et la restauration de données historiques au-delà des opérations DDL ne sont pas prises en charge. Par exemple, vous ne pouvez pas utiliser le flashback natif pour interroger le contenu d'une table qui a été supprimée.

Syntaxe

Le flashback natif introduit la clause AS OF pour spécifier l'instant auquel interroger ou restaurer les données. La syntaxe est la suivante :

SELECT ... FROM <table_name>
  AS OF TIMESTAMP <expression>;

L'expression spécifie l'instant cible et prend en charge plusieurs formats. Exemples :

SELECT ... FROM tablename
  AS OF TIMESTAMP '2020-11-11 00:00:00';

SELECT ... FROM tablename
  AS OF TIMESTAMP now();

SELECT ... FROM tablename
  AS OF TIMESTAMP (SELECT now());

SELECT ... FROM tablename
  AS OF TIMESTAMP DATE_SUB(now(), INTERVAL 1 minute);

Paramètres

Les paramètres suivants contrôlent le comportement du flashback natif :

Exemples

# Get the current timestamp.
MySQL [mytest]> select now();
+---------------------+
| now()               |
+---------------------+
| 2020-10-14 15:44:09 |
+---------------------+
1 row in set (0.00 sec)

# View the data.
MySQL [mytest]> select * from mt1;
+----+------+
| id | c1   |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec)

# Run an update operation without a WHERE clause.
MySQL [mytest]> update mt1 set c1 = 100;
Query OK, 5 rows affected (0.00 sec)
Rows matched: 5  Changed: 5  Warnings: 0

MySQL [mytest]> select * from mt1;
+----+------+
| id | c1   |
+----+------+
|  1 |  100 |
|  2 |  100 |
|  3 |  100 |
|  4 |  100 |
|  5 |  100 |
+----+------+
5 rows in set (0.00 sec)

# Query the historical data at the specified point in time. The query returns the expected result.
MySQL [mytest]> select * from mt1 AS OF timestamp '2020-10-14 15:44:09';
+----+------+
| id | c1   |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec)

# If the specified time is outside the retention window for historical data, the query fails.
MySQL [mytest]> select * from mt1 AS OF timestamp '2020-10-13 14:44:09';
ERROR 7545 (HY000): The snapshot to find is out of range

# Start the data recovery.
MySQL [mytest]> create table mt1_tmp like mt1; # Create a temporary table with the same structure as the original table.
Query OK, 0 rows affected (0.03 sec)  
MySQL [mytest]> insert into mt1_tmp
             -> select * from mt1 AS OF
             -> TIMESTAMP '2020-10-14 15:44:09'; # Insert the historical data from the original table into the temporary table. 
Query OK, 5 rows affected (0.01 sec) 
Records: 5  Duplicates: 0  Warnings: 0 
MySQL [mytest]> select * from mt1_tmp; # Verify that the data in the temporary table is correct. 
+----+------+
| id | c1   |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec) 
MySQL [mytest]> rename table mt1 to mt1_bak,
             -> mt1_tmp to mt1; # (Before you perform this operation, stop all read and write operations on the table.) Rename the original table to mt1_bak and the temporary table to mt1 to complete the data recovery.
Query OK, 0 rows affected (0.02 sec)
MySQL [mytest]> select * from mt1; # Verify the restored data. 
+----+------+
| id | c1   |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+ 
5 rows in set (0.01 sec)