5.1 利用 GC 快照读恢复数据

当遇到数据被误更新或误删除的情况,很多人想到的是 Oracle 的闪回或者 MySQL 的基于 binlog 实现的闪回工具。作为 NewSQL 的佼佼者,TiDB 可以直接通过标准 SQL 读取历史数据,无需特殊的 client 或者 driver。即使在更新/删除数据后,表结构发生了变化,TiDB 依旧能够按照旧的表结构定义将数据读取出来。

5.1.1 历史数据保留策略

TiDB 事务的实现采用了 MVCC(多版本并发控制)机制,当更新/删除数据时,不会做真正的数据删除,只会添加一个新版本数据,并以时间戳来区分版本。当然历史数据不会永久保留,超过一定时间的历史数据将会被彻底删除,以减小空间占用,同时避免因历史版本过多引起的性能开销。

TiDB 使用周期性运行的 GC(Garbage Collection,垃圾回收)来进行清理,默认情况下每 10 分钟一次。每次 GC 时,TiDB 会计算一个称为 safe point 的时间戳(默认为上次运行 GC 的时间减去 10 分钟),接下来 TiDB 会在保证在 safe point 之后的快照都能够读取到正确数据的前提下,删除更早的过期数据。

TiDB 的 GC 相关的配置存储于 mysql.tidb 系统表中,可以通过 SQL 语句对这些参数进行查询和更改:

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like 'tikv_gc%';

+--------------------------+----------------------------------------------------------------------------------------------------+
| VARIABLE_NAME            | VARIABLE_VALUE                                                                                     |
+--------------------------+----------------------------------------------------------------------------------------------------+
| tikv_gc_leader_uuid      | 5afd54a0ea40005                                                                                    |
| tikv_gc_leader_desc      | host:tidb-cluster-tidb-0, pid:215, start at 2019-07-15 11:09:14.029668932 +0000 UTC m=+0.463731223 |
| tikv_gc_leader_lease     | 20190715-12:12:14 +0000                                                                            |
| tikv_gc_enable           | true                                                                                               |
| tikv_gc_run_interval     | 10m0s                                                                                              |
| tikv_gc_life_time        | 10m0s                                                                                              |
| tikv_gc_last_run_time    | 20190715-12:09:14 +0000                                                                            |
| tikv_gc_safe_point       | 20190715-11:59:14 +0000                                                                            |
| tikv_gc_auto_concurrency | true                                                                                               |
| tikv_gc_mode             | distributed                                                                                        |
+--------------------------+----------------------------------------------------------------------------------------------------+
13 rows in set (0.00 sec)

例如,如果需要将 GC 调整为保留最近一天以内的数据,只需执行下列语句即可:

update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";

注意: mysql.tidb系统表中除了下文将要列出的 GC 的配置外,还包含一些 TiDB 用于储存部分集群状态(包括 GC 状态)的记录。请勿手动更改这些记录。其中,与 GC 有关的记录如下:

. tikv_gc_leader_uuid,tikv_gc_leader_desc 和 tikv_gc_leader_lease 用于记录 GC leader 的状态

. tikv_gc_last_run_time:上次 GC 运行时间

. tikv_gc_safe_point:当前 GC 的 safe point

. tikv_gc_life_time: 用于配置历史版本保留时间,可以手动修改

. tikv_gc_safe_point: 记录了当前的 safe point,用户可以安全地使用大于 safe point 的时间戳创建 Snapshot 读取历史版本。safe point 在每次 GC 开始运行时自动更新。

5.1.2 查询历史数据

读取历史版本数据前,需设定一个系统变量: tidb_snapshot ,这个变量是 Session 范围有效级别,可以通过标准的 Set 语句修改其值。其值可以是 TSO 或日期时间。TSO 是全局授时的时间戳,是从 PD 端获取的; 日期时间的格式可以为: “2016-10-08 16:45:26.999”,一般来说可以只写到秒,比如”2016-10-08 16:45:26”。 当这个变量被设置后,TiDB 会用这个时间戳建立 Snapshot(没有开销,只是创建数据结构),之后所有的查询操作都会在这个 Snapshot 上读取数据。

注意: TiDB 的事务是通过 PD 进行全局授时,所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时,是以 tidb_snapshot 变量的值作为版本号,如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大,需要以 PD 的时间为准。

当读取历史版本数据操作结束后,可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 “",即可读取最新版本的数据。

5.1.3 查询历史数据示例:

1.初始化阶段,创建一个表,并插入几行数据:

create table t (c int);
Query OK, 0 rows affected (0.01 sec)

insert into t values (1), (2), (3);
Query OK, 3 rows affected (0.00 sec)

2.查看表中的数据:

select * from t;
+------+
| c    |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

3.查看当前时间:

select now();
+---------------------+
| now()               |
+---------------------+
| 2016-10-08 16:45:26 |
+---------------------+
1 row in set (0.00 sec)

4.更新某一行数据:

update t set c=22 where c=2;
Query OK, 1 row affected (0.00 sec)

5.确认数据已经被更新:

select * from t;
+------+
| c    |
+------+
|    1 |
|   22 |
|    3 |
+------+
3 rows in set (0.00 sec)

6.设置一个特殊的环境变量,这个是一个 session scope 的变量,其意义为读取这个时间之前的最新的一个版本。

set @@tidb_snapshot="2016-10-08 16:45:26";
Query OK, 0 rows affected (0.00 sec)

注意: 这里的时间设置的是 update 语句之前的那个时间。在 tidb_snapshot 前须使用 @@ 而非 @,因为 @@ 表示系统变量,@ 表示用户变量。

这里读取到的内容即为 update 之前的内容,也就是历史版本:

select * from t;
+------+
| c    |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

7.清空这个变量后,即可读取最新版本数据:

set @@tidb_snapshot="";
Query OK, 0 rows affected (0.00 sec)

select * from t;
+------+
| c    |
+------+
|    1 |
|   22 |
|    3 |
+------+
3 rows in set (0.00 sec)

注意: 在 tidb_snapshot 前须使用 @@ 而非 @,因为 @@ 表示系统变量,@ 表示用户变量。

5.1.4 恢复被更新/删除的数据

通过读取历史数据可以快速恢复被更新/删除的数据,大致步骤如下:

注意: 此方法仅适用变化的数据量较少的情况,进行恢复时需要调整gc的生命周期。

1、调整 GC 保留时间,如将 GC 调整为保留最近一天以内的数据。

update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";

说明: 具体保留多长时间,需要结合业务进行评估

2、创建一个与待恢复的数据表同结构的临时表,如:

set @@tidb_snapshot="2016-10-08 16:45:26";
create table t_20161008 like t;

3、按照业务逻辑将需要的数据插入到临时表:

insert into t_20161008 select * from t where c=2;

4、按照业务逻辑将数据从临时表反更新或插入到原表

5、按照业务逻辑校验数据

6、将 GC 保留时长调整为恢复之前的设置

update mysql.tidb set VARIABLE_VALUE="10m0s" where VARIABLE_NAME="tikv_gc_life_time"

7、根据需要删除临时表

results matching ""

    No results matching ""