PolarDB:Flashback query

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Un cluster PolarDB for MySQL répondant à l'une des exigences de version suivantes :

  • PolarDB for MySQL 8.0.2, version de révision 8.0.2.2.21 ou ultérieure

  • PolarDB for MySQL 8.0.1, version de révision 8.0.1.1.32 ou ultérieure

  • PolarDB for MySQL 5.7, version de révision 5.7.1.0.25 ou ultérieure

  • PolarDB for MySQL 5.6, version de révision 5.6.1.0.36 ou ultérieure

• Le paramètre innodb_backquery_enable activé sur la page Parameters de votre cluster. Ce paramètre est désactivé par défaut.

L'exécution d'une requête Flashback avant l'activation de innodb_backquery_enable renvoie l'erreur ERROR 1815 (HY000): Internal error: the backquery_time set is out of range, too old .

Pour vérifier la version de votre cluster, consultez Interroger le numéro de version.

Fonctionnement

PolarDB stocke les versions historiques des lignes dans les journaux d'annulation InnoDB. Lors d'une requête Flashback, PolarDB parcourt la chaîne des journaux d'annulation de chaque ligne pour reconstruire les données telles qu'elles existaient à l'instant spécifié.

La fenêtre temporelle disponible pour les requêtes dépend de innodb_backquery_window (valeur par défaut : 86 400 secondes) et de la capacité des journaux d'annulation définie par innodb_backquery_capacity_limit. Lorsque la limite de capacité est atteinte, la fenêtre temporelle effective se réduit. Une fenêtre temporelle plus large accroît l'utilisation du tablespace Undo et peut réduire légèrement les performances en écriture.

Syntaxe

Toutes les requêtes Flashback ajoutent la clause AS OF TIMESTAMP time_expr à la référence de table.

Requête sur table unique

SELECT column_name_list FROM table_name AS OF TIMESTAMP time_expr [alias] [WHERE ...];

Requête multi-tables

SELECT column_name_list
FROM table1_name AS OF TIMESTAMP time_expr [alias1],
     table2_name AS OF TIMESTAMP time_expr [alias2]
[WHERE ...];

Requête JOIN multi-tables

SELECT column_name_list
FROM table1_name AS OF TIMESTAMP time_expr [alias1]
JOIN table2_name AS OF TIMESTAMP time_expr [alias2] ON join_cond1
JOIN table3_name AS OF TIMESTAMP time_expr [alias3] ON join_cond2
[WHERE ...];

Paramètres

Paramètres

Interroger des données historiques

Cet exemple montre comment utiliser une requête Flashback pour consulter des données antérieures à leur modification.

Étape 1 : Préparer les données de test

À 2021-08-31 13:51, créez la table products et insérez cinq lignes.

CREATE TABLE products (
    prod_id    BIGINT(10) PRIMARY KEY NOT NULL,
    prod_name  VARCHAR(20) NOT NULL,
    cust_id    BIGINT(10) NULL,
    createtime DATETIME NOT NULL DEFAULT NOW()
);

INSERT INTO products (prod_id, prod_name, cust_id, createtime)
VALUES
    (101, 'Book',   1, NOW()),
    (102, 'Apple',  1, NOW()),
    (103, 'Beef',   2, NOW()),
    (104, 'Bread',  3, NOW()),
    (105, 'Cheese', 4, NOW());

Étape 2 : Vérifier les données initiales

SELECT * FROM products;

+---------+-----------+---------+---------------------+
| prod_id | prod_name | cust_id | createtime          |
+---------+-----------+---------+---------------------+
|     101 | Book      |       1 | 2021-08-31 13:51:22 |
|     102 | Apple     |       1 | 2021-08-31 13:51:24 |
|     103 | Beef      |       2 | 2021-08-31 13:51:26 |
|     104 | Bread     |       3 | 2021-08-31 13:51:27 |
|     105 | Cheese    |       4 | 2021-08-31 13:51:29 |
+---------+-----------+---------+---------------------+
5 rows in set (0.00 sec)

Étape 3 : Mettre à jour les données

À 2021-08-31 14:18, mettez à jour deux lignes.

UPDATE products SET prod_id = 110, createtime = NOW() WHERE prod_name = 'Book';
UPDATE products SET prod_id = 119, createtime = NOW() WHERE prod_name = 'Apple';

La table se présente désormais ainsi :

+---------+-----------+---------+---------------------+
| prod_id | prod_name | cust_id | createtime          |
+---------+-----------+---------+---------------------+
|     103 | Beef      |       2 | 2021-08-31 13:51:26 |
|     104 | Bread     |       3 | 2021-08-31 13:51:27 |
|     105 | Cheese    |       4 | 2021-08-31 13:51:29 |
|     110 | Book      |       1 | 2021-08-31 14:18:21 |
|     119 | Apple     |       1 | 2021-08-31 14:18:22 |
+---------+-----------+---------+---------------------+
5 rows in set (0.00 sec)

Étape 4 : Interroger le snapshot historique

Lisez la table telle qu'elle existait à 2021-08-31 14:00:00, soit après la création des lignes mais avant leur mise à jour.

SELECT * FROM products AS OF TIMESTAMP '2021-08-31 14:00:00';

+---------+-----------+---------+---------------------+
| prod_id | prod_name | cust_id | createtime          |
+---------+-----------+---------+---------------------+
|     101 | Book      |       1 | 2021-08-31 13:51:22 |
|     102 | Apple     |       1 | 2021-08-31 13:51:24 |
|     103 | Beef      |       2 | 2021-08-31 13:51:26 |
|     104 | Bread     |       3 | 2021-08-31 13:51:27 |
|     105 | Cheese    |       4 | 2021-08-31 13:51:29 |
+---------+-----------+---------+---------------------+
5 rows in set (0.00 sec)

Limitations

• Requêtes sur table unique uniquement. Évitez les requêtes Flashback dans des requêtes complexes impliquant des jointures (JOIN) ou des sous-requêtes. Bien que la syntaxe prenne en charge les requêtes multi-tables, les performances se dégradent lors de jointures complexes.

• Clé primaire obligatoire. Les requêtes Flashback s'appuient sur la clé primaire. Une requête sur un index secondaire entraîne un balayage complet de la table, ce qui réduit les performances.

• Lectures de snapshot uniquement. Les requêtes Flashback fonctionnent avec des lectures de snapshot. Les lectures avec verrouillage renvoient l'erreur This query in backquery is not a consistent read, please check.. Les types d'instructions suivants déclenchent une lecture avec verrouillage et ne sont pas pris en charge :

  -- S LOCK (REPEATABLE-READ isolation level or higher)
  INSERT INTO t1 SELECT * FROM t2
  REPLACE INTO t1 SELECT * FROM t2
  UPDATE t SET ... FROM (SELECT ...) AS h
  CREATE TABLE t1 AS SELECT * FROM t2
  
  -- S LOCK
  UPDATE t1 JOIN (SELECT ...) t2 ON ... SET ...
  SELECT * FROM t LOCK IN SHARE MODE
  
  -- X LOCK
  SELECT * FROM t FOR UPDATE

• Les opérations DDL interrompent l'accès historique. Après une opération DDL, vous ne pouvez plus exécuter de requête Flashback sur les données antérieures à cette opération. Toute tentative d'interrogation de ces données peut renvoyer l'erreur Backquery primary key invisible.

• Limite de 100 000 versions par ligne. Chaque ligne peut comporter au maximum 100 000 versions historiques. Les requêtes portant sur des lignes dépassant cette limite renvoient record undo history version exceed limit.

• Tables supprimées. Une requête Flashback peut lire une table supprimée après l'activation de la fonctionnalité, mais pas une table supprimée avant cette activation.

• Croissance des journaux d'annulation. L'activation de la requête Flashback entraîne la croissance du tablespace Undo dans la fenêtre temporelle configurée, phénomène amplifié en présence de BLOB. Cette croissance peut réduire légèrement les performances en écriture. Surveillez l'utilisation du tablespace Undo et ajustez innodb_backquery_window ainsi que innodb_backquery_capacity_limit pour équilibrer la plage de requête et la surcharge de stockage.

Étapes suivantes

• Interroger le numéro de version