PolarDB:Flashback query

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

• Un clúster de PolarDB for MySQL que cumpla con alguno de los siguientes requisitos de versión:

  • PolarDB for MySQL 8.0.2, versión de revisión 8.0.2.2.21 o posterior

  • PolarDB for MySQL 8.0.1, versión de revisión 8.0.1.1.32 o posterior

  • PolarDB for MySQL 5.7, versión de revisión 5.7.1.0.25 o posterior

  • PolarDB for MySQL 5.6, versión de revisión 5.6.1.0.36 o posterior

• El parámetro innodb_backquery_enable habilitado en la página Parameters de su clúster. Este parámetro está deshabilitado de forma predeterminada.

Si ejecuta una consulta Flashback antes de habilitar innodb_backquery_enable , el sistema devuelve ERROR 1815 (HY000): Internal error: the backquery_time set is out of range, too old .

Para obtener instrucciones sobre cómo comprobar la versión de su clúster, consulte Query the version number.

Cómo funciona

PolarDB almacena las versiones históricas de las filas en los registros undo de InnoDB. Cuando ejecuta una consulta Flashback, PolarDB recorre la cadena de registros undo de cada fila para reconstruir los datos tal como existían en la marca de tiempo especificada.

La ventana de tiempo disponible para las consultas está limitada por innodb_backquery_window (valor predeterminado: 86400 segundos) y por la capacidad del registro undo configurada mediante innodb_backquery_capacity_limit. Al alcanzar el límite de capacidad, la ventana de tiempo efectiva se reduce. Una ventana de tiempo más amplia incrementa el uso del tablespace Undo y puede reducir ligeramente el rendimiento de escritura.

Sintaxis

Todas las consultas Flashback agregan AS OF TIMESTAMP time_expr a la referencia de la tabla.

Consulta de una sola tabla

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

Consulta de varias tablas

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

Consulta JOIN de varias tablas

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 ...];

Parámetros

Parámetros

Consultar datos históricos

En este ejemplo se muestra cómo usar una consulta Flashback para consultar los datos antes de que se modificaran.

Paso 1: Preparar los datos de prueba

A las 2021-08-31 13:51, cree la tabla products e inserte cinco filas.

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());

Paso 2: Comprobar los datos iniciales

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)

Paso 3: Actualizar los datos

A las 2021-08-31 14:18, actualice dos filas.

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

Ahora la tabla tiene el siguiente aspecto:

+---------+-----------+---------+---------------------+
| 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)

Paso 4: Consultar la instantánea histórica

Lea la tabla tal como existía a las 2021-08-31 14:00:00, es decir, después de crear las filas pero antes de actualizarlas.

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)

Limitaciones

• Solo consultas de una sola tabla. Evite usar consultas Flashback en consultas complejas que incluyan JOIN o subconsultas. Aunque la sintaxis admite consultas de varias tablas, el rendimiento disminuye en combinaciones complejas.

• Clave primaria obligatoria. Las consultas Flashback dependen de la clave primaria. Si consulta mediante un índice secundario, el sistema recurre a un escaneo completo de la tabla, lo cual reduce el rendimiento.

• Solo lecturas de instantáneas. Las consultas Flashback funcionan con lecturas de instantáneas. Las lecturas con bloqueo devuelven el error This query in backquery is not a consistent read, please check.. Los siguientes tipos de instrucciones activan una lectura con bloqueo y no son compatibles:

  -- 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

• Las operaciones DDL interrumpen el acceso al historial. Después de ejecutar una operación DDL, no es posible lanzar una consulta Flashback sobre los datos anteriores a dicha operación. Si intenta consultarlos, el sistema podría devolver el error Backquery primary key invisible.

• Límite de 100,000 versiones por fila. Cada fila puede tener un máximo de 100,000 versiones históricas. Las consultas sobre filas que superan este límite devuelven record undo history version exceed limit.

• Tablas eliminadas. Una consulta Flashback puede leer una tabla eliminada después de habilitar la función, pero no una eliminada antes de habilitarla.

• Crecimiento del registro undo. Habilitar la consulta Flashback hace que el tablespace Undo crezca dentro de la ventana de tiempo configurada, y aún más en escenarios con BLOB. Este crecimiento puede reducir ligeramente el rendimiento de escritura. Supervise el uso del tablespace Undo y ajuste innodb_backquery_window y innodb_backquery_capacity_limit para equilibrar el rango de consulta frente al consumo de almacenamiento.

Pasos siguientes

• Query the version number