mysql 备份表无法恢复_MySQL删库不跑路-无备份Drop表恢复

最新推荐文章于 2024-05-24 09:58:08 发布
最新推荐文章于 2024-05-24 09:58:08 发布
阅读量149 收藏 1
点赞数
文章标签： mysql 备份表无法恢复

3d17ec87ff86c1f17d864b4c456eee3c.png

MySQL删库不跑路-无备份Drop恢复

说在前头

库一定要备份！！！

库一定要备份！！！

库一定要备份！！！

由于当前环境基本上都会开启 innodb_file_per_table ，因此测试 innodb_file_per_table = 1 情况下的数据恢复，innodb_file_per_table = 0 的操作差不多

  • 不要太指望工具能恢复户多少数据，会有多种情况花式丢页数据，导致无法恢复
  • 现象1：drop table 后，有DDL操作 + insert ..select 操作，丢失页
  • 现象2：使用命令行shutdown库或kill 进程，丢失页
  • 各种花式丢页，所以备份一定要做好，不要太指望这个

环境

MySQL 5.7.27-log

系统： CentOS Linux release 7.6.1810

恢复工具: undrop-for-innodb

[ https:// github.com/twindb/undro p-for-innodb ](twindb/undrop-for-innodb)

恢复工具安装

git clone twindb/undrop-for-innodb
yum install -y make gcc flex bison
cd undrop-for-innodb/
make
完成后当前目录下出现可执行文件 c_parser 和 stream_parser

表结构恢复工具安装

cd undrop-for-innodb/
[root@testinit undrop-for-innodb]# gcc `/usr/local/mysql/bin/mysql_config --cflags` `/usr/local/mysql/bin/mysql_config --libs` -o sys_parser sys_parser.c
/usr/local/mysql/bin 是当前mysql安装的 basedir,完成后当前目录下会出现可执行文件 sys_parser

模拟数据表误删

root@mysqldb 04:27:  [none]> create database dtest;
Query OK, 1 row affected (0.00 sec)

root@mysqldb 04:27:  [(none)]> use dtest
Database changed

root@mysqldb 04:27:  [(dtest)]>
CREATE TABLE `dtest1` ( `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` varchar(10) DEFAULT NULL,
  `b` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4;

root@mysqldb 22:38:  [dtest]> insert into dtest1 values(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

root@mysqldb 04:27:  [dtest]> update dtest1 set b = '222' where id = 2;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

root@mysqldb 04:27:  [dtest]> checksum table dtest1;
+--------------+------------+
| Table        | Checksum   |
+--------------+------------+
| dtest.dtest1 | 3175768141 |
+--------------+------------+
1 row in set (0.00 sec)

root@mysqldb 04:28:  [dtest]> select * from dtest1;
+----+------+------+
| id | a    | b    |
+----+------+------+
|  1 | 1    | 1    |
|  2 | 2    | 222  |
|  3 | 3    | 3    |
|  4 | 4    | 4    |
|  5 | 5    | 5    |
+----+------+------+
5 rows in set (0.00 sec)

root@mysqldb 04:30:  [dtest]> create table dtest2 like dtest1;
Query OK, 0 rows affected (0.02 sec)

root@mysqldb 04:30:  [dtest]> create table dtest3 like dtest1;
Query OK, 0 rows affected (0.01 sec)

root@mysqldb 04:30:  [dtest]> insert into dtest2 select * from dtest1;
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

root@mysqldb 04:30:  [dtest]> alter table dtest3 add c varchar(10);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

root@mysqldb 04:32:  [dtest]> insert into dtest3 select t.*,'123456' from dtest1 t;
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

# 模拟误删表
root@mysqldb 04:32:  [dtest]> drop table dtest1;
Query OK, 0 rows affected (0.00 sec)

# 误删后肯定还会有其他业务会在操作其他表,模拟还有其他操作
root@mysqldb 04:34:  [dtest]> update dtest2 set b = 'bbbbbbbb' where id = 2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

备份复制一份进行恢复【也可以不操作这一步，直接分析源库的】

  • 可以不停止源MySQL,但若出现DDL操作，可能会导致数据丢失恢复不出来
  • 停机并拷贝备份，业务无法停机也能直接操作下一步，停机是为了降低莫名丢页问题
  • 不要 kill 进程，不要在mysql命令项内执行 shutdown来关闭Mysql
mysqladmin -uroot -S /tmp/mysql.sock shutdown 或 service mysqld stop
cp -R /data/mysql_data/ /data/mysql_data2

获取表对应页

当前操作在源库上操作，mysql已关闭

1-解析ibdata1

[root@testinit undrop-for-innodb]# ./stream_parser -f /data/mysql_data/ibdata1
Opening file: /data/mysql_data/ibdata1
File information:

ID of device containing file:        64768
inode number:                     16935187
protection:                         100640 (regular file)
number of hard links:                    1
user ID of owner:                      998
group ID of owner:                    1000
device ID (if special file):             0
blocksize for filesystem I/O:         4096
number of blocks allocated:        2097152
time of last access:            1589574685 Sat May 16 04:31:25 2020
time of last modification:      1589574876 Sat May 16 04:34:36 2020
time of last status change:     1589574876 Sat May 16 04:34:36 2020
total size, in bytes:           1073741824 (1.000 GiB)

Size to process:                1073741824 (1.000 GiB)
Worker(0): 3.12% done. 2020-05-16 04:37:21 ETA(in 00:00:41). Processing speed: 24.000 MiB/sec
...省略
All workers finished in 11 sec

2-解析数据文件所在磁盘页

[root@testinit undrop-for-innodb]# df -k
Filesystem              1K-blocks    Used Available Use% Mounted on
/dev/mapper/centos-root  15767552 8275312   7492240  53% /
devtmpfs                   485780       0    485780   0% /dev
tmpfs                      497948       0    497948   0% /dev/shm
tmpfs                      497948    7728    490220   2% /run
tmpfs                      497948       0    497948   0% /sys/fs/cgroup
/dev/sda1                 1038336  135380    902956  14% /boot
tmpfs                       99592       0     99592   0% /run/user/0

[root@testinit undrop-for-innodb]# ./stream_parser -f /dev/mapper/centos-root -t 15767552k
Opening file: /dev/mapper/centos-root
File information:

ID of device containing file:            5
inode number:                        18278
protection:                          60660 (block device)
number of hard links:                    1
user ID of owner:                        0
group ID of owner:                       6
device ID (if special file):         64768
blocksize for filesystem I/O:         4096
number of blocks allocated:              0
time of last access:            1589538693 Fri May 15 05:31:33 2020
time of last modification:      1589538693 Fri May 15 05:31:33 2020
time of last status change:     1589538693 Fri May 15 05:31:33 2020
total size, in bytes:                    0 (0.000 exp(+0))

Size to process:               16145973248 (15.037 GiB)
Worker(0): 1.09% done. 2020-05-15 05:52:55 ETA(in 00:11:07). Processing speed: 22.813 MiB/sec
Worker(0): 2.13% done. 2020-05-15 05:46:34 ETA(in 00:04:43). Processing speed: 53.234 MiB/sec
...省略
All workers finished in 85 sec
完成后当前目录下会生成俩个page开头的文件
pages-centos-root
pages-ibdata1

解析页获取表结构与表对应页ID

1-找到表的ID

[root@testinit undrop-for-innodb]# ./c_parser -6Df ./pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t ./dictionary/SYS_TABLES.sql | grep 'dtest/dtest1'
SET FOREIGN_KEY_CHECKS=0;
LOAD DATA LOCAL INFILE '/root/undrop-for-innodb/dumps/default/SYS_TABLES' REPLACE INTO TABLE `SYS_TABLES` CHARACTER SET UTF8 FIELDS TERMINATED BY 't' OPTIONALLY ENCLOSED BY '"' LINES STARTING BY 'SYS_TABLESt' (`NAME`, `ID`, `N_COLS`, `TYPE`, `MIX_ID`, `MIX_LEN`, `CLUSTER_NAME`, `SPACE`);
-- STATUS {"records_expected": 54, "records_dumped": 6, "records_lost": true} STATUS END
000000000B06	260000002F0221	SYS_TABLES	"dtest/dtest1"	40	3	33	0	80	""	28
000000000B06	260000002F0221	SYS_TABLES	"dtest/dtest1"	40	3	33	0	80	""	28
表ID为表名后面的那个数字，这里为 40

2-利用找出来的表ID，查找数据所在的磁盘页ID

[root@testinit undrop-for-innodb]# ./c_parser -6Df ./pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t ./dictionary/SYS_INDEXES.sql | grep 40
SET FOREIGN_KEY_CHECKS=0;
LOAD DATA LOCAL INFILE '/root/undrop-for-innodb/dumps/default/SYS_INDEXES' REPLACE INTO TABLE `SYS_INDEXES` CHARACTER SET UTF8 FIELDS TERMINATED BY 't' OPTIONALLY ENCLOSED BY '"' LINES STARTING BY 'SYS_INDEXESt' (`TABLE_ID`, `ID`, `NAME`, `N_FIELDS`, `TYPE`, `SPACE`, `PAGE_NO`);
-- STATUS {"records_expected": 64, "records_dumped": 8, "records_lost": true} STATUS END
000000000B06	260000002F0145	SYS_INDEXES	40	41	"PRIMARY"	1	3	28	4294967295
000000000B06	260000002F0145	SYS_INDEXES	40	41	"PRIMARY"	1	3	28	4294967295
一般会在 0000000000000003.page 中找到，若不存在，则使用下面的语句循环查一下看看 
for i in `ls ./pages-ibdata1/FIL_PAGE_INDEX/`; do echo "$i"; ./c_parser -6Df ./pages-ibdata1/FIL_PAGE_INDEX/$i -t ./dictionary/SYS_INDEXES.sql | grep -w 40; done
这里可以看到，ID 40 对应的page页为 41，41就是表数据所在磁盘页

3-查看对应的页是否存在

查看恢复页存不存在，不存在则凉凉，当前示例需要查看对应的页 41 是否存在

ls ./pages-centos-root/FIL_PAGE_INDEX/

4-获取表结构(若已知被删除表的表结构，这一步跳过)

上面的页已分析完毕，可以启动mysql了【之前没关的话，忽略】

mysqld_safe --user=mysql &

4.1-执行recover_dictionary.sh

执行undrop-for-innodb目录下的recover_dictionary.sh，会创建一个`test`库，并生成SYS开头的4张表，若test库已存在，则直接生成在这个库下

[root@testinit undrop-for-innodb

生成库表如下：

root@mysqldb 06:21:  [(none)]> use test;
Database changed

root@mysqldb 06:21:  [test]> show tables;
+----------------+
| Tables_in_test |
+----------------+
| SYS_COLUMNS    |
| SYS_FIELDS     |
| SYS_INDEXES    |
| SYS_TABLES     |
+----------------+
4 rows in set (0.00 sec)

可以查看字典信息同样得知表ID与对应页ID

root@mysqldb 06:22:  [(none)]> use test
Database changed

# 获得表ID 40
root@mysqldb 06:22:  [test]> select * from SYS_TABLES where name like 'dtest/dtest1';
+--------------+----+--------+------+--------+---------+--------------+-------+
| NAME         | ID | N_COLS | TYPE | MIX_ID | MIX_LEN | CLUSTER_NAME | SPACE |
+--------------+----+--------+------+--------+---------+--------------+-------+
| dtest/dtest1 | 40 |      3 |   33 |      0 |      80 |              |    28 |
+--------------+----+--------+------+--------+---------+--------------+-------+
1 row in set (0.00 sec)

# 获得页ID 41
root@mysqldb 06:22:  [test]> select * from SYS_INDEXES where table_id=40;
+----------+----+---------+----------+------+-------+------------+
| TABLE_ID | ID | NAME    | N_FIELDS | TYPE | SPACE | PAGE_NO    |
+----------+----+---------+----------+------+-------+------------+
|       40 | 41 | PRIMARY |        1 |    3 |    28 | 4294967295 |
+----------+----+---------+----------+------+-------+------------+
1 row in set (0.00 sec)

4.2-获得结构

# 创建libmysqlclient.so.20软链，否则可能报错
[root@testinit undrop-for-innodb]# ln -s /usr/local/mysql-5.7.27-linux-glibc2.12-x86_64/lib/libmysqlclient.so.20 /usr/lib64/libmysqlclient.so.20

# 密码要写上去，可以创建个权限高一点的，用完删除这个用户
[root@testinit undrop-for-innodb]# ./sys_parser -h 127.0.0.1 -u root -p123456 -d test dtest/dtest1
CREATE TABLE `dtest1`(
	`id` INT NOT NULL,
	`a` VARCHAR(10) CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_general_ci',
	`b` VARCHAR(10) CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_general_ci',
	PRIMARY KEY (`id`)
) ENGINE=InnoDB;

解析页数据导出

1-创建需恢复表的表结构SQL

[root@testinit undrop-for-innodb]# cat /tmp/dtest1.sql
CREATE TABLE `dtest1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` varchar(10) DEFAULT NULL,
  `b` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

2 查看数据是否存在【可略】

# 查看数据
[root@testinit undrop-for-innodb]# ./c_parser -6f pages-centos-root/FIL_PAGE_INDEX/0000000000000041.page -t /tmp/dtest1.sql |head -5
SET FOREIGN_KEY_CHECKS=0;
LOAD DATA LOCAL INFILE '/root/undrop-for-innodb/dumps/default/dtest1' REPLACE INTO TABLE `dtest1` CHARACTER SET UTF8 FIELDS TERMINATED BY 't' OPTIONALLY ENCLOSED BY '"' LINES STARTING BY 'dtest1t' (`id`, `a`, `b`);
-- STATUS {"records_expected": 5, "records_dumped": 5, "records_lost": false} STATUS END
-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)
000000000907	A7000000250110	dtest1	1	"1"	"1"
00000000090C	2A000000300110	dtest1	2	"2"	"222"
000000000907	A7000000250128	dtest1	3	"3"	"3"
000000000907	A7000000250134	dtest1	4	"4"	"4"
00000B18    B3000000290134    da    4    "4"    "4"
0000000000000041.page 上面查出的对应的页ID文件

3-创建指定的恢复目录

mkdir -p /root/undrop-for-innodb/dumps/default

4-数据导出

./c_parser -6f pages-centos-root/FIL_PAGE_INDEX/0000000000000041.page -t /tmp/dtest1.sql > dumps/default/dtest1 2> dumps/default/dtest1.sql
dumps/default 这个目录不要更改

恢复数据到mysql

# 登陆mysql
mysql -uroot -p

# 切换到指定库
root@mysqldb 06:25:  [(none)]> use dtest

# 生成对应表，或手动创建
root@mysqldb 06:25:  [dtest]> source /tmp/dtest1.sql

# 导入数据
root@mysqldb 06:26:  [dtest]>  source /root/undrop-for-innodb/dumps/default/dtest1.sql
Query OK, 0 rows affected (0.00 sec)

Query OK, 5 rows affected (0.00 sec)
Records: 5  Deleted: 0  Skipped: 0  Warnings: 0

数据验证

root@mysqldb 06:28:  [dtest]> show tables;
+-----------------+
| Tables_in_dtest |
+-----------------+
| dtest1          |
| dtest2          |
| dtest3          |
+-----------------+
3 rows in set (0.00 sec)

root@mysqldb 06:28:  [dtest]> select * from dtest1;
+----+------+------+
| id | a    | b    |
+----+------+------+
|  1 | 1    | 1    |
|  2 | 2    | 222  |
|  3 | 3    | 3    |
|  4 | 4    | 4    |
|  5 | 5    | 5    |
+----+------+------+
5 rows in set (0.00 sec)
weixin_39849894
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Mysql在Centos下，InnoDB数据损坏导致服务不可用
qq_16557863的博客
10-27 626
早上发现公司的测试环境的mysql又又又挂了，上面一百多个库，测试同事要炸锅了。之前都是备份一下，然后恢复临时解决问题，今天打算换个思路来处理这个问题，先检查一下进程是否存在。扫描过后，通过检查输出记录，发现好几张表的索引文件损坏了，关闭innodb_force_recovery参数，重启mysql，发现服务可以正常启动了。先尝试配置1，然后启动mysql，启动这个后，数据库会锁定插入和修改等操作，只能读。先打开配置中的innodb_force_recovery，这个配置。执行后，倒是没影响程序。
mysql delete表或drop表恢复
Du.的博客
03-29 1231
由drds闪回和回收站功能引发的测试 1. delete表恢复 （1）背景：误操作delete没有where限制，mysql binlog开启 mysql> select * from zhongwen2; +----+--------------+ | id | name | +----+--------------+ | 1 | 沈阳 | | 2 | 沈阳 | | 3 | æ·»åŠ | | 4 | 添加...
推荐：TwinDB 数据恢复工具包 - UnDrop for InnoDB
最新发布
gitblog_00020的博客
05-24 270
推荐：TwinDB 数据恢复工具包 - UnDrop for InnoDB 项目地址:https://gitcode.com/twindb/undrop-for-innodb 在数据世界中，意外的丢失往往带来严重后果，但有了TwinDB Data Recovery Toolkit，即知名的UnDrop for InnoDB，你可以对数据库恢复有全新的信心。这个开源项目是一个强大的工具集，专门针对M...
MySQL表和表数据被删除后，紧急复原
NiKaBoy的博客
09-02 1万+
在开发和在生产中总会出现各种各样的失误和意味，当MySQL的数据或表被删除后不要慌，执行以下命令，查看mysql是否开启binlog，binlog会记录下数据库表结构的变更，因此。在找到binlog文件就需要确定我们要恢复的范围，因为每个mysql-bin可能内容很多，我们需要根据时间区间，截取出需要数据恢复的那一部分。是一个比较好用的mysql闪回工具，建议去上面的github查看，有例子，基本不踩坑，步骤也很简单，使用。根据这两个参数进行数据恢复，使用以下指令，在服务器中执行。在部署MySQL的时候。.
MySQL 8.0 drop table恢复
fanzhuozhuo的博客
01-15 3371
MySQL 8.0 drop table恢复环境信息思路梳理恢复过程sysbench 造数据，压测xtrabackup全备数据库模拟drop table查找drop前的GTID创建必要的数据文件目录和日志文件目录和参数文件恢复数据库修改权限，启动3308实例配置为从库恢复表 关于MySQL的drop table可能有很多恢复的方法，下面说一种，基于全备，复制，然后让sql_thread停在一个指定位置的方法来恢复。下面进行模拟恢复 环境信息 MySQL版本信息：Server version: 8.0.27
MySQL Drop Database之后的恢复测试
weixin_33781606的博客
12-20 651
工具介绍工具的名字叫做: undrop-for-innodb代码地址: https://github.com/twindb/undrop-for-innodb官方文档： https://recovery.twindb.com/介绍工具的一篇ppt http://www.slideshare.net/akuzminsky/undrop-for-innodb当MySQL 执...
无备份情况下恢复MySQL误删的表，这样做再也不用怕误删了
热门推荐
u011277123的博客
09-18 4万+
小码农大世界 2017-09-14 21:52 上一篇文章聊了下session的基本原理，这两天想了下如何更好的了解session，及随着系统越来越大会碰到的问题。 这里我们假设服务器是一家公司，那么session就充当了看门大爷的角色。 用户想要进入我们的公司，我们总不能随随便便让人进入。这时候看门大爷就要求你记录的个人信息，来就是来访记录。然而用户可能办完一件事就走了，等下次
MySQL使用全库备份数据恢复单表数据的方法
09-09
这个过程适用于需要快速恢复单个表的情况，避免了全库恢复的耗时。但需要注意的是，这种方法可能会丢失在备份后到恢复期间产生的新数据，因此在进行此类操作时，要确保在合适的时间点进行，并考虑可能的数据一致性...
从MySQL全库备份中恢复某个库和某张表的方法
09-09
总结来说，恢复MySQL全库备份中的特定数据库或表，主要依赖于`mysqldump`工具和正则表达式的应用。在进行这些操作时，需要注意数据一致性，避免因错误操作导致数据丢失。此外，根据实际场景选择合适的数据恢复策略，...
MySQL 从全库备份中恢复指定的表和库示例
09-09
在MySQL数据库管理中，有时我们需要从全库备份中恢复特定的表或库，而不是整个数据库。这在数据恢复或迁移场景中尤其有用。本示例将详细介绍如何使用MySQL的Mysqldump工具来实现这一目标。 首先，我们来看如何进行...
深入浅析MySQL从删库到跑路_高级（一）——数据完整性
09-09
在实际操作中，应谨慎处理数据，尤其是在执行删除操作时，以避免可能导致数据丢失或破坏数据完整性的行为，比如“删库跑路”这样的极端情况。因此，数据库管理策略和备份计划是保障数据安全的重要环节。
没有备份怎么恢复被drop的表(利用undrop-for-innodb)
weixin_34113237的博客
08-04 308
介绍:     也许大家都难以理解,这么重要的数据为啥不备份(或者备份不可用)?而且还任性的drop table了。显然有备份是最好的，但是它们并不总是可用的。这种情况令人恐惧，但并非毫无希望。在许多情况下，可以恢复数据库或表中的几乎所有数据。恢复计划取决于InnoDB是否将所有数据保存在一个ibdata1中，还是每个表都有自己的表空间。本文将考虑innodb_file_per_table=OFF...
mysql undrop_MySQL中使用undrop来恢复drop的表（上）-阿里云开发者社区
weixin_30666313的博客
01-26 74
MySQL中可以使用编程语言(比如Python)来解析binlog中DML的逆操作来达到闪回的效果，如果数据不多，手工解析也可以。这也是现在大家碰到的很多DML Flashback的一个基本原理。而如果是DDL，比如DROP,那就得叹声气了。GitHub上有一个很不错的项目是undrop,基于InnoDB,也就意味着如果你所在的环境有了drop操作还是存在恢复的可能了，当然这个过程需要谨慎，建议大...
【数据库数据恢复】MySQL数据库误删除未备份的数据恢复案例
beiya123的博客
12-07 2198
MySQL数据库数据恢复环境： 本地服务器，操作系统为windows server； 部署mysql单实例，引擎类型为innodb，表空间类型为独立表空间； 没有数据库备份，未开启binlog。 MySQL数据库故障： 用户使用Delete命令删除数据时未添加where子句进行筛选，导致全表数据被删除，删除后再未对该表做任何操作。
mysql删除的表怎么恢复_误删除mysql数据库表该如何恢复操作方法
weixin_34466909的博客
01-28 4476
误删除mysql数据库表该如何恢复操作方法发布时间：2020-05-07 16:29:08来源：亿速云阅读：221作者：三月本文主要给大家介绍误删除mysql数据库表该如何恢复操作方法，文章内容都是笔者用心摘选和编辑的，具有一定的针对性，对大家的参考意义还是比较大的，下面跟笔者一起了解下误删除mysql数据库表该如何恢复操作方法吧。一、实验环境：1、准备两台虚拟机，一台用于破坏数据库，一台用于还原...
linux运维笔记：Mysql备份与恢复
一个好知识的传播者
10-16 798
备份是数据安全的最后一道防线，对于任何数据丢失的场景，备份虽然不一定能恢复百分之百的数据(取决于备份周期)，但至少能将损失降到最低。增量数据就是指上一次全量备份数据之后到下一次全备之前数据库所更新的数据，对于mysqldump，binlog就是增量数据。--master-data=1|2 #告诉备份时刻的binlog位置。-x, --lock-all-tables #锁所有备份表。全量数据就是数据库中所有的数据（或某一个库的全部数据）。-l, --lock-tables #锁单表。
mysql undrop_使用undrop-for-innodb工具在无备份的情况下恢复mysql表
weixin_30315143的博客
01-26 444
背景最近一个朋友说，程序误删了一张表，但是没有备份。我一心想，这不是凉凉了。因为按照正常的情况，如果误删了表，在有备份的情况下，可以通过备份+binlog的方式找回数据。如果没有备份的话，想找回数据基本是没什么希望了。本着死马当活马医的态度，在网上google了一阵，发现了竟然还有undrop-for-innodb这一个工具。undrop-for-innodb工具按照描述，是可以实现在无备份的情况...
使用undrop-for-innodb恢复delete数据
w574951402的博客
07-15 548
mysql innodb引擎数据库，无binlog情况下，恢复delete数据过程记录
mysql如何从备份表中恢复 3 个表?
06-09
要从 MySQL 备份中恢复 3 个表，需要执行以下步骤： 1. 创建一个新的数据库，用于恢复备份的表。 2. 使用以下命令恢复备份文件到新创建的数据库中： ``` mysql -u username -p new_database < backup_file.sql ``` 其中，`username` 是 MySQL 用户名，`new_database` 是新创建的数据库名，`backup_file.sql` 是备份文件名。 3. 查看备份文件中的表名，找到需要恢复的 3 个表。 4. 使用以下命令将这 3 个表从备份文件中恢复到新创建的数据库中： ``` mysql -u username -p new_database -e "source backup_file.sql; INSERT INTO target_table SELECT * FROM source_table WHERE id IN (1, 2, 3);" ``` 其中，`username` 是 MySQL 用户名，`new_database` 是新创建的数据库名，`backup_file.sql` 是备份文件名，`target_table` 是要恢复的目标表名，`source_table` 是备份文件中的源表名，`(1, 2, 3)` 是要恢复的记录的 ID。 重复执行这个命令，将所有需要恢复的表都恢复到新数据库中即可。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值