TiDB数据丢失快速恢复实验07.txt

兜兜

225

3页

0次

2022-11-21

10墨值下载

实验一：DML 方式操作的数据恢复---tidb_snapshot

实验二：恢复被 DDL 操作 truncate 的表----dumpling+flashback

实验三：恢复被 DDL 操作 drop 的表----recover(两次 drop)

实验背景：使用 tidb_snapshot 参数来读取历史数据(mvcc 版本)就那些数据恢复。

实验一：DML 方式操作的数据恢复---tidb_snapshot

1.初始化环境

use test

create table t1 (id int);

insert into t1 values(1),(2),(3);

select * from t1;

2.查看此时的时间，并记录下来

select now(); #2022-05-26 09:59:24

3.模拟误操作 DML 操作---delete

delete from t1 where id=3;

select * from t1;

4. 确认 GC 清理周期是否满足要求

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like

"tikv_gc%"; #查看 tikv_gc_life_time 和 tikv_gc_safe_point，默认 lift_ time 是 10 分

钟

update mysql.tidb set VARIABLE_VALUE="60m" where

VARIABLE_NAME="tikv_gc_life_time"; #修改 lift_ time 为 1 小时，这样避免 MVCC 的历史数

据被清理

5.开始恢复数据

set @@tidb_snapshot="2022-05-26 09:59:24"; #这个在第二步中记录 DML 误操作的时间

select * from t1; #检查数据是否是误操作之前的数据(3 条数

据)，并将此时的数据复制或记录下来，便于下面步骤手工修改

6.如何将此历史版本数据恢复

方法一：使用 dumpling 中的参数--snapshot 参数，这种方法适合于被修改的数据量很多的情况

方法二：手工或者脚本去修改，这样方法适合于被修改的数量很少的情况(本实验采用的方法)

set @@tidb_snapshot=""; #还原此会话的 snapshot

select * from t1; #此时为误操作之后的正常表数据(只要 2 条)

insert into t1 values(3); #根据历史版本数据，将误操作数据进行还原

select * from t1;

7.还原 GC 的清理周期时间

update mysql.tidb set VARIABLE_VALUE="10m" where

VARIABLE_NAME="tikv_gc_life_time";

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like

"tikv_gc%";

实验二：恢复被 DDL 操作 truncate 的表----dumpling+flashback

1.初始化环境

use test

create table t2 (id int);

insert into t2 values(1),(2),(3);

select * from t2;

2.第一次误操作 truncate

truncate table t2;

select * from t2;

3. 模拟此时生产环境继续生成数据--第一次

insert into t2 values(4),(5),(6);

select * from t2;

4.第二次误操作 truncate

truncate table t2;

select * from t2;

5. 模拟此时生产环境继续生成数据--第二次

insert into t2 values(7),(8),(9),(10);

select * from t2;

6.数据恢复，要求将第一次 truncate 和第二次 truncate 数据都找回，并恢复到 t2 表中，完整数据为 1-

10.

6.1 确认 GC 清理周期是否满足要求

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like

"tikv_gc%"; #查看 tikv_gc_life_time 和 tikv_gc_safe_point，默认 lift_ time 是 10 分

钟

update mysql.tidb set VARIABLE_VALUE="60m" where

VARIABLE_NAME="tikv_gc_life_time"; #修改 lift_ time 为 1 小时，这样避免 MVCC

的历史数据被清理

6.2 查询表 t2 的 DDL 操作发生时间

admin show ddl jobs where table_name='t2'; #记录下第一次 truncate 和第二次

truncate 的时间,2022-05-26 10:00:47 / 2022-05-26 10:01:11

6.3 恢复第一次 truncate 的数据

set tidb_snapshot="";

select * from t2;

PS：由于 Flashback 只能恢复 DDL(drop/truncate)最近一次的操作，且不能与 tidb_snapshot 一起

使用，所有此时只能使用 ddumpling 方式备份出历史版本数据

#控制节点上执行

cd /tidb/soft/tidb-toolkit-v5.4.0-linux-amd64/bin/

./dumpling -h 192.168.10.91 -P 4000 -u root --filetype sql -t 32 -F 256m -T

test.t2 --snapshot "2022-05-26 10:00:47" -o /tidb/backup/t2_dump_$(date +%F)

more /tidb/backup/t2_dump_2022-05-26/test.t2.000000000.sql #与业务确认恢复数

据，确认以后将数据导入会现数据库中 t2 表

source /tidb/backup/t2_dump_2022-05-26/test.t2.000000000.sql

select * from t2; #此时有 7 条数据

select count(*) from t2;

6.4 恢复第二次 truncate 的数据（当然这里也可以使用 dumpling 方式，但是使用 flashback 更加方

便）

flashback table t2 to t2_bak;

select * from t2_bak; #与业务确认恢复数据(此时数据应为 3

条分别是 4,5,6)，确认以后将数据导入会现数据库中 t2 表

insert into t2 select * from t2_bak;

select * from t2; #此时完整的数据恢复完成，一共 10 条。

实验一：DML 方式操作的数据恢复---tidb_snapshot

实验二：恢复被 DDL 操作 truncate 的表----dumpling+flashback

实验三：恢复被 DDL 操作 drop 的表----recover(两次 drop)

实验背景：使用 tidb_snapshot 参数来读取历史数据(mvcc 版本)就那些数据恢复。

实验一：DML 方式操作的数据恢复---tidb_snapshot

1.初始化环境

use test

create table t1 (id int);

insert into t1 values(1),(2),(3);

select * from t1;

2.查看此时的时间，并记录下来

select now(); #2022-05-26 09:59:24

3.模拟误操作 DML 操作---delete

delete from t1 where id=3;

select * from t1;

4. 确认 GC 清理周期是否满足要求

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like

"tikv_gc%"; #查看 tikv_gc_life_time 和 tikv_gc_safe_point，默认 lift_ time 是 10 分

钟

update mysql.tidb set VARIABLE_VALUE="60m" where

VARIABLE_NAME="tikv_gc_life_time"; #修改 lift_ time 为 1 小时，这样避免 MVCC 的历史数

据被清理

5.开始恢复数据

set @@tidb_snapshot="2022-05-26 09:59:24"; #这个在第二步中记录 DML 误操作的时间

select * from t1; #检查数据是否是误操作之前的数据(3 条数

据)，并将此时的数据复制或记录下来，便于下面步骤手工修改

6.如何将此历史版本数据恢复

方法一：使用 dumpling 中的参数--snapshot 参数，这种方法适合于被修改的数据量很多的情况

方法二：手工或者脚本去修改，这样方法适合于被修改的数量很少的情况(本实验采用的方法)

set @@tidb_snapshot=""; #还原此会话的 snapshot

select * from t1; #此时为误操作之后的正常表数据(只要 2 条)

insert into t1 values(3); #根据历史版本数据，将误操作数据进行还原

select * from t1;

7.还原 GC 的清理周期时间

update mysql.tidb set VARIABLE_VALUE="10m" where

VARIABLE_NAME="tikv_gc_life_time";

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like

"tikv_gc%";

实验二：恢复被 DDL 操作 truncate 的表----dumpling+flashback

1.初始化环境

use test

create table t2 (id int);

insert into t2 values(1),(2),(3);

select * from t2;

2.第一次误操作 truncate

truncate table t2;

select * from t2;

3. 模拟此时生产环境继续生成数据--第一次

insert into t2 values(4),(5),(6);

select * from t2;

4.第二次误操作 truncate

truncate table t2;

select * from t2;

5. 模拟此时生产环境继续生成数据--第二次

insert into t2 values(7),(8),(9),(10);

select * from t2;

6.数据恢复，要求将第一次 truncate 和第二次 truncate 数据都找回，并恢复到 t2 表中，完整数据为 1-

10.

6.1 确认 GC 清理周期是否满足要求

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like

"tikv_gc%"; #查看 tikv_gc_life_time 和 tikv_gc_safe_point，默认 lift_ time 是 10 分

钟

update mysql.tidb set VARIABLE_VALUE="60m" where

VARIABLE_NAME="tikv_gc_life_time"; #修改 lift_ time 为 1 小时，这样避免 MVCC

的历史数据被清理

6.2 查询表 t2 的 DDL 操作发生时间

admin show ddl jobs where table_name='t2'; #记录下第一次 truncate 和第二次

truncate 的时间,2022-05-26 10:00:47 / 2022-05-26 10:01:11

6.3 恢复第一次 truncate 的数据

set tidb_snapshot="";

select * from t2;

PS：由于 Flashback 只能恢复 DDL(drop/truncate)最近一次的操作，且不能与 tidb_snapshot 一起

使用，所有此时只能使用 ddumpling 方式备份出历史版本数据

#控制节点上执行

cd /tidb/soft/tidb-toolkit-v5.4.0-linux-amd64/bin/

./dumpling -h 192.168.10.91 -P 4000 -u root --filetype sql -t 32 -F 256m -T

test.t2 --snapshot "2022-05-26 10:00:47" -o /tidb/backup/t2_dump_$(date +%F)

more /tidb/backup/t2_dump_2022-05-26/test.t2.000000000.sql #与业务确认恢复数

据，确认以后将数据导入会现数据库中 t2 表

source /tidb/backup/t2_dump_2022-05-26/test.t2.000000000.sql

select * from t2; #此时有 7 条数据

select count(*) from t2;

6.4 恢复第二次 truncate 的数据（当然这里也可以使用 dumpling 方式，但是使用 flashback 更加方

便）

flashback table t2 to t2_bak;

select * from t2_bak; #与业务确认恢复数据(此时数据应为 3

条分别是 4,5,6)，确认以后将数据导入会现数据库中 t2 表

insert into t2 select * from t2_bak;

select * from t2; #此时完整的数据恢复完成，一共 10 条。

of 3

10墨值下载

tidb

关注

评论