devbox
我家自动化
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

数据库｜恢复的方式多种多样，总有一款适合你

作者：我家自动化 | 2024-03-22 10:41:45

赞

踩

数据库｜恢复的方式多种多样，总有一款适合你

相信大家在日常的工作中都有遇见过需要恢复数据库的情况，那么在工作中我们要如何确保高效迅速地恢复数据呢？

本篇文章为大家带了几种详细的恢复方式！

目录

一、GC时间内的恢复

1.1 表的数据量很小，通过工具导出

1.2 表的数据量中等，百万级别，考虑一下使用loaddata

1.3 表数据很大，千万级以上，建议用Dumpling + Lightning

二、gc时间外，异机恢复

2.1 binlog恢复

2.2 br full + br log

三、总结

一、GC时间内的恢复

简单解释下，tidb有个参数，tidb_gc_life_time ，一般默认是10分钟。建议适当加大。

查询方式：

select @@tidb_gc_life_time;

再不行就看grafana里，tikv-details> gc 有个TiKV Auto GC SafePoint，只要是在这个时间之后的，都可以通过下面3个方式恢复。

1.1 表的数据量很小，通过工具导出

set @@tidb_snapshot="2023-11-12 10:53:26";

导出，这个就看你的工具了，一般的Navicat就挺好用的。

导入一样用工具，记得建个新表。

1.2 表的数据量中等，百万级别，考虑一下使用loaddata

loaddata导出

  1. set @@tidb_snapshot="2023-11-12 10:53:26";
  2. SELECT * FROM t10 INTO OUTFILE '/tmp/t10.csv'
  3. FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
  4. LINES TERMINATED BY '\r\n'
  5. ;

loaddata导入

  1. set session tidb_batch_commit=50000;
  2. LOAD DATA LOCAL INFILE
  3. '/tmp/t10.csv'
  4. INTO TABLE t10_bak
  5. FIELDS TERMINATED BY ','  
  6. ENCLOSED BY '\"'
  7. LINES TERMINATED BY '\r\n' (id, name, id2);
留个疑问，仔细查下tidb_batch_commit参数，你会发现官方不推荐设置这个参数，这个会破坏事务一致性的，为什么我要在导入前加入这个参数呢？

加戏——指定列导入

  1. LOAD DATA LOCAL INFILE '/tmp/t14.csv' INTO TABLE t14 FIELDS TERMINATED BY ',' ENCLOSED BY '\"' LINES TERMINATED BY '\r\n'
  2. (@C1,@C2,@C3,@C4,@C5 )
  3. set row_id=@C1,
  4.     name=@C2,
  5.     id=@C4,
  6.     c=@C5;

非常规使用tidb，就造就了一些场景需要指定列导入：

  1. 表中存在虚拟列
  2. 想在导入阶段对值做些处理

1.3 表数据很大，千万级以上，建议用Dumpling + Lightning

dumpling导出

（官方参数就挺好用，搬运一下）

  1. ./dumpling -u root -P 4900 -h 127.0.0.1 -o /tmp/test \
  2. --snapshot "2023-12-05 15:12:45" \
  3. --filetype csv -F 100MiB \
  4. -T test.t4

Lightning导入

（也是从官方参数就挺好用，搬运一下）

建议使用tidb模式，可以满足大部分场景的需求了。如果确实速度太慢，表太大，可以优先调整参数region-concurrency。

  1. [lightning]
  2. # 日志
  3. level = "info"
  4. file = "/tmp/tidb-lightning.log"
  5. check-requirements = true
  6. [mydumper]
  7. data-source-dir = "/tmp/test"
  8. [tikv-importer]
  9. backend = "tidb"
  10. [tidb]
  11. host = "127.0.0.1"
  12. port = 4000
  13. user = "root"
  14. password = ""
  15. log-level = "error"

./tidb-lightning --config /tmp/lightning.toml

导出常见报错如下，请检查gc时间，数据被gc了，再次强调默认数据库的tidb_gc_life_time时间为10m。

请使用异机恢复方式。

  1. create dumper failed: fail to set snapshot for tidb, please set 
  2. --consistency=none/--consistency=lock or fix snapshot problem: Error 8055:
  3. snapshot is older than GC safe point 2023-12-05 14:27:33.218 +0800 CST

导入有同名表需要注意下，直接导入是不会报错的，会清理数据，建议手动改下导出的文件，换个表名。最好是空库导入

以下是一些的尝试，验证了一下该操作的可行性：

1.尝试直接insert，报错明显，语法不通。

  1. MySQL [test]> insert into t5 select * from t4 as of timestamp '2023-12-06 08:45:26';
  2. ERROR 8135 (HY000): can not set different time in the as of

2.设置了快照时间insert后，我收到了一个表不存在的报错。最初，我感到困惑，因为我以为我操作的是刚刚新建的表。然而，经过仔细思考，我意识到报错其实并无问题，因为在那个历史时间点下，数据库中确实没有这个表。

  1. MySQL [test]> set @@tidb_snapshot='2023-12-06 08:45:26';
  2. Query OK, 0 rows affected (0.00 sec)
  3. MySQL [test]> insert into t5 select * from t4 ;
  4. ERROR 1146 (42S02): Table 'test.t5' doesn't exist

3.即便我预感可能会出错，尝试预先建立空表备用，最终还是遇到了报错。这次报错更直接，明确指出在快照下无法修改数据。这让我意识到快照的特性限制了对数据的修改操作。

  1. MySQL [test]> set @@tidb_snapshot='2023-12-06 09:13:00';
  2. Query OK, 0 rows affected (0.01 sec)
  3. MySQL [test]> insert into t5 select * from t4 ;
  4. ERROR 1105 (HY000): can not execute write statement when 'tidb_snapshot' is set

已经踩过的雷，看到的人就不要再踩了。老老实实正规操作。

1.4 本地恢复drop table、truncate table

a. 本地恢复drop table、truncate table

Flashback table

truncate需要把现有表换名

b. 6.5以上版本又多了两个功能

整个集群闪退Flashback cluster

单个database级别drop闪回

flashback database database_name to database_name;

不知道大家有没有发现一个小技巧，tidb在6.5是不支持直接rename database，但是可以通过flashback database换名。

二、gc时间外，异机恢复

没有全备和没有日志的就别妄想恢复了，该醒醒了，赶紧配吧，别等真的需要再搞。如果真的有方法，偷偷告诉我，我想学。

2.1 binlog恢复

当集群配置有pump和drainer的时候，就可以使用全备（一般都是dumpling）+增量的binlog，配置有全备和全备时间点后的增量binlog日志。

全备恢复工具lighting，不再赘述。

增量恢复工具reparo配置文件，注意stop-tso可以写时间的。

  1. data-dir = "/tidb-data4/binlog"
  2. log-level = "info"
  3.  
  4. start-tso = "2023-12-02 15:04:05"
  5. stop-datetime  = "2023-12-02 15:04:05"
  6. dest-type = "mysql"
  7. safe-mode = false
  8. [[replicate-do-table]]
  9. db-name ="test"
  10. tbl-name = "t4"
  11.  
  12. [dest-db]
  13. host = "127.0.0.1"
  14. port = 4000
  15. user = "root"
  16. password = "xxxxxxxxxxx"
./reparo -config reparo.toml

再稍微说下reparo，binlog解析工具，不仅可以做增量恢复，还可以dest-type = "print"导出sql文本。比如只是误删一部分数据，就可以解析问题时间段日志就行了。

2.2 br full + br log

br用于全备的库，要求还是比较多的，一般要挂cos或nas，不然备到本地，恢复的时候还需要手动整合到一起。

br相当于binglog组件虽然要求多，但是真的快，毕竟是相当于物理级别的cp，记忆犹新一个大库dump一天搞不完，用br搞2个多小时，当然要cos或者nas也足够快。

br log是pitr，是直接从kv取的增量变化，这个也是需要挂cos或nas用于存储。

br恢复的命令比较简单了，把全备恢复和增量恢复整合在了一起，很友好。

  1. tiup br restore point \
  2. --pd="10.3.72.75:2979" \
  3. --full-backup-storage='/tidbbackup/brfull/' \
  4. --storage "/tidbbackup/brlog/"

简单看下效果

  1. tiup is checking updates for component br ...
  2. Starting component `br`: /home/db/tidb/.tiup/components/br/v6.5.3/br restore point --pd=10.3.72.75:2979 --full-backup-storage=/tidbbackup/brfull/ --storage /tidbbackup/brlog/
  3. Detail BR log in /tmp/br.log.2023-12-05T10.29.16+0800
  4. Full Restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
  5. [2023/12/05 10:29:23.647 +08:00] [INFO] [collector.go:73] ["Full Restore success summary"] [total-ranges=29] [ranges-succeed=29] [ranges-failed=0] [split-region=655.559µs] [restore-ranges=12] [total-take=7.100235857s] [total-kv-size=504.4MB] [average-speed=71.04MB/s] [restore-data-size(after-compressed)=27.13MB] [Size=27131118] [BackupTS=446101705187131404] [RestoreTS=446101810752520193] [total-kv=254138]
  6. Restore Meta Files <-------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
  7. Restore KV Files <---------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
  8. [2023/12/05 10:29:24.702 +08:00] [INFO] [collector.go:73] ["restore log success summary"] [total-take=1.054945723s] [restore-from=446101705187131404] [restore-to=446101733590433793] [restore-from="2023-12-05 10:22:34.968 +0800"] [restore-to="2023-12-05 10:24:23.318 +0800"] [total-kv-count=12] [total-size=1.947kB] [average-speed=1.846kB/s]

可以看到先做的是Full Restore 全备，后面做的restore log增量恢复。

三、总结

所有恢复前提，就是你要了解数据库的恢复的前提条件具不具备，比如说gc设置1天，一天做一次全备不做增备，能恢复什么时间点的数据。

为了确保今后在遇到误操作删数据问题时能够迅速、有效地解决，请重视备份。本篇也是想总结下各个恢复手段，希望能帮助到大家！

如果有什么不对，还请多多指正！

作者 ：叶小普 | 高级数据库运维工程师

版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。

公众号搜索神州数码云基地，后台回复数据库，加入数据库技术交流群。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家自动化/article/detail/287411
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号