精华内容
下载资源
问答
  • 本文将介绍当我们使用mysql不小心删库之后,或者恶意被删库后,如何进行数据恢复 流程 我们进行数据恢复的前提是: 1、必须开启binlog日志功能 2、最好是会对数据进行定期备份(否则数据量太大的情况下很难通过...

    前言

    本文将介绍当我们使用mysql不小心删库之后,或者恶意被删库后,如何进行数据恢复

    binlog

    我们进行数据恢复的前提是:

    • 1、必须开启binlog日志功能
    • 2、最好是会对数据进行定期备份(否则数据量太大的情况下很难通过binlog进行恢复)

    我们先来了解下binlog

    binlog是mysql server层提供的功能,和存储引擎无关,binlog保存了所有服务端执行的DDL和DML语句。

    所以在binlog完整的情况下,可以理解为当被删库后可以把所有DML语句重新执行一遍来达到数据恢复

    binlog的作用:

    • 1、做日志恢复
    • 2、主从架构时做数据同步

    准备

    首先我们自己先部署一个mysql,部署的流程这里不介绍。

    然后修改配置文件,笔者这里是使用docker启动的mysql,修改容器内部配置文件:
    /etc/mysql/mysql.conf.d/mysqld.cnf,如果不是容器的话目录应该是/etc/my.cnf文件,如图

    在这里插入图片描述
    log-bin:指定binlog的目录
    expire_logs_day:保留多少天内的日志,如果希望全量保存则可以不设置
    server_id:主从架构时使用,这里使用binlog也需要设置,否则可能报错

    我们先创建了一些初始化数据
    在这里插入图片描述
    创建了db1、db2数据库以及一些数据

    然后我们看下当前binlog的状态:

    使用mysql连接:mysql -uroot -p123456;

    执行:show master status;

    查看下当前binlog的最后一个文件以及position

    position:可以理解为当前写到该binlog文件的哪个位置
    在这里插入图片描述

    备份

    接下来我们开始备份数据库

    使用mysql的mysqldump工具进行备份所有数据库

    执行:mysqldump -F -R -x -uroot -p123456 --all-databases >/db_all_20210202_19_21.sql
    在这里插入图片描述
    这里解释下:

    -F:等同于–flush-logs: 在执行导出前先刷新binlog日志文件,一般来说,如果是全库导出,建议先刷新日志文件
    -R,: 导出存储过程以及自定义函数
    -x, 等同于–lock-all-tables: 在导出任务执行期间锁定所有数据库中的所有表,以保证数据的一致性。这是一个全局锁定,并且自动关闭–single-transaction 和–lock-tables 选项。这个参数副作用比较大,这是全库锁定,备份执行过程中,该库无法进行读写操作,不是所有业务场景都能接受的。请慎用。(读写操作无法执行)

    此时的binlog应该是一个新的文件了,我们连接后再看下
    在这里插入图片描述
    也就是说我们备份的文件db_all_20210202_19_21.sql包含了binlog文件mysql-bin.000014之前的所有数据

    然后我们又写了一些数据
    在这里插入图片描述

    现在有人恶意删库跑路了!!!

    我们的所有数据库都被删除了,我们尝试进行恢复数据

    我们首先需要找到binlog文件删库的日志是记录在哪里的,这里主要根据时间来依次查找下

    先看下当前有哪些binlog日志文件,直接在binlog日志目录下查看
    在这里插入图片描述
    我们在mysql-bin.000014-mysql-bin.000017之间查找删库语句

    执行:mysqlbinlog -v /var/lib/binlog/mysql-bin.000014; 可以查看binlog详细日志,以及操作的时间。先定位到删库的时间,然后寻找对应的删库操作,我们这里是手动删除db1和db2的,根据时间先定位到了是在日志文件mysql-bin.000014

    然后执行:show binlog events in ‘mysql-bin.000014’;
    在这里插入图片描述
    可以看到position 984到1231为我们的删库语句日志,所以我们需要先恢复到position 984之前

    此时如果整个mysql的的存储目录都被删掉了,则需要重新安装下mysql或者想办法生成一份初始化的存储目录文件

    笔者是使用docker安装的,所以重启了docker即重新生成了,重启后的文件如下
    在这里插入图片描述

    1、我们先恢复到我们上述的备份包

    执行:mysql -uroot -p123456 </db_all_20210202_19_21.sql

    在这里插入图片描述
    执行后查看数据,发现db1和db2都已经恢复了,但是后续增加的name=7、8、9三条数据丢失了
    在这里插入图片描述

    2、我们基于binlog恢复备份包到删库之前的数据

    执行:mysqlbinlog --start-position=1 --stop-position 984 /var/lib/binlog/mysql-bin.000014 | mysql -uroot -p;

    然后查看数据库表,发现数据已经完整了,如果此时还需要后面的数据,那么依次恢复mysql-bin.000015、mysql-bin.000016、mysql-bin.000017的数据即可
    在这里插入图片描述

    总结

    本文介绍的只是基础的数据恢复流程,仅限学习。真正的DBA维护数据库肯定没有这么简单。

    注意点:

    • 1、必须定期备份完整数据库以及开启binlog日志,binlog日志的目录必须放好,如果binlog的日志也被删除了,那么数据就很难全量恢复了
    • 2、需要考虑备份数据库时的数据一致性,因为当数据量大时备份比较耗时,而这个时候肯定不能把库表全部锁住,本文为了演示才进行锁表备份(可以考虑停掉一个从库,在从库上备份数据,完成后再连接到主库),另外mysqldump据说在数据量大时比较耗时,DBA可能会采取其他的备份手段
    展开全文
  • 在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...

    昨天因为不可描述的原因,数据库直接被 drop database删除。在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。

    第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后向万能的朋友圈求救,朋友给了两个链接,最终救了一下命。以下先按编号记下 URL,后续引用之。

    1. dba.stackexchange.com/questions/2…
    2. github.com/chhabhaiya/…
    3. twindb.com/how-to-reco…

    其中URL1和URL3的内容基本上相同,是整个恢复工作的蓝本。URL2是URL1中引用的一个twindb团队开发的一个工具,现在他们官方已经删除了,URL2是该工具的一个fork,或者说是备份。

    恢复过程以URL3为蓝本,先去URL2 git clone一份代码下来,然后按其说明编译,我们在ubuntu server 14.04 64bit 版本的情况下,成功编译完成,编译中需要安装各种依赖不表。

    然后用 stream_parser 处理ibdata1 文件,接下来恢复SYS_TABLESSYS_INDEXES,建议此过程中严格遵守参考资料,比如把这些资料恢复到dumps/default 目录中,而不是随意起名,以免横生枝节。

    这里还有一个坑,就是URL3里用的c_parser -4f 是会出错的,而URL1里用的是c_parser -4Df ,就不会出错,所以大家做的时候一定要把这个D加上。感叹一下,如果不细心的人真的没法做这事!摔!

    接下来按URL3的说明把数据字典导入 MySQL。这一步可以不做,按URL1里高票答案的方法来获取索引ID,比较麻烦。URL3的方法应该会出这样的错:

    1
    ERROR 1148 (42000) at line 2: The used command is not allowed with this MySQL version

    这是因为MySQL默认不启用LOAD DATA LOCAL INFILE 导致的,需要给mysql 命令加上--local-infile 参数。这是参考文献的一个坑。趟过这个坑以后,我可以告诉你一个捷径,就是URL2里的代码里其实有一个文件recover_dictionary.sh ,它干的就是恢复数据字典的事情,所以你只要把这个shell脚本里的mysql 都替换成mysql --local-infile -uroot -pxxxxx 就行,其中xxxx是指你的root账号密码,不过前提是你很听话的用了前面说的dumps/default 目录,不然就再多一轮替换。

    接下来的内容,大部分是参考文献里没有的了。

    恢复数据字典后,就可以用URL3介绍的方式找出你对应的所有数据库和表的索引ID了。这个时候就遇到为 c_parser 提供数据表建表语句的问题了,这个问题难就难在先有鸡还是先有蛋,一般来说,数据库都被删掉了,哪还有办法去搞出CREATE TABLE 这种建表语句呢?好就好在我们用的是django,它对数据迁移的完美支持救了我一命。在这里讲一句题外话,使用类似django/ror/laravel等有数据迁移框架在此就看出多么重要了。只要在根据原有项目做一次migrate,数据表就建好了,这时候只要用mysqldump导出对应表的建表语句即可:

    1
    mysqldump --add-drop-table=0 --add-lock=0 -d DBNAME TABLENAME -uroot -p > xxxx.sql

    因为c_parser 非常弱,只处理CREATE TABLE 语句,多一点干扰都不行,所以上面的参数都是必要的。

    接下来就是参考URL1把某一个表的数据恢复出来,这里有一个坑,URL1里说把数据恢复到dump.tsv里,其实是不对的,这里应该用dumps/default/TABLENAME,别问我为什么知道,我不会告诉你我找这个原因找瞎了眼,好吧,跟你说,因为生成的load_cmd.sql 里直接引用 dumps/default/TABLENAME,无法设置。所以最后我们这里可用的命令是:

    1
    ./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000002410.page -t xxxx.sql > dumps/default/TABLENAME 2> load_cmd.sql

    把数据恢复出来以后,执行

    1
    mysql --local-infile -uroot -p DBNAME < load_cmd.sql

    就可以把数据导进去了,记得在数据库里查询一下有没有成功,如果没有数据恢复出来,应该是其中的某些环节出了问题。

    这样就成功恢复了某一个表,只要按这里最后三条命令(导出建表语句、恢复数据、导入数据)重复地做下去,你就能把基本上所有的数据都恢复出来了。之所以说是“基本上”,原因是我系统中使用了utf8mb4 编码(为了兼容emoji),结果是如果数据中有emoji的内容就会在导入数据的环节出错,暂时没有找到办法恢复这个数据。

    以上就是整个恢复过程,枯燥、压力山大,这种事情我不想再经历了。如果你也遇到这样的数据恢复需求,希望这篇笔记能够帮到你。


    展开全文
  • 记一次MySQL删库的数据恢复

    万次阅读 2016-11-25 21:43:49
    在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...

    这里写图片描述
    昨天因为不可描述的原因,数据库直接被 drop database删除。在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。

    第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后向万能的朋友圈求救,朋友给了两个链接,最终救了一下命。以下先按编号记下 URL,后续引用之。

    1. http://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database
    2. https://github.com/chhabhaiya/undrop-for-innodb
    3. https://twindb.com/how-to-recover-innodb-dictionary/

    其中URL1和URL3的内容基本上相同,是整个恢复工作的蓝本。URL2是URL1中引用的一个twindb团队开发的一个工具,现在他们官方已经删除了,URL2是该工具的一个fork,或者说是备份。

    恢复过程以URL3为蓝本,先去URL2 git clone一份代码下来,然后按其说明编译,我们在ubuntu server 14.04 64bit 版本的情况下,成功编译完成,编译中需要安装各种依赖不表。

    然后用 stream_parser 处理ibdata1 文件,接下来恢复SYS_TABLESSYS_INDEXES,建议此过程中严格遵守参考资料,比如把这些资料恢复到dumps/default 目录中,而不是随意起名,以免横生枝节。

    这里还有一个坑,就是URL3里用的c_parser -4f 是会出错的,而URL1里用的是c_parser -4Df ,就不会出错,所以大家做的时候一定要把这个D加上。感叹一下,如果不细心的人真的没法做这事!摔!

    接下来按URL3的说明把数据字典导入 MySQL。这一步可以不做,按URL1里高票答案的方法来获取索引ID,比较麻烦。URL3的方法应该会出这样的错:

    ERROR 1148 (42000) at line 2: The used command is not allowed with this MySQL version

    这是因为MySQL默认不启用LOAD DATA LOCAL INFILE 导致的,需要给mysql 命令加上--local-infile 参数。这是参考文献的一个坑。趟过这个坑以后,我可以告诉你一个捷径,就是URL2里的代码里其实有一个文件recover_dictionary.sh ,它干的就是恢复数据字典的事情,所以你只要把这个shell脚本里的mysql 都替换成mysql --local-infile -uroot -pxxxxx 就行,其中xxxx是指你的root账号密码,不过前提是你很听话的用了前面说的dumps/default 目录,不然就再多一轮替换。

    接下来的内容,大部分是参考文献里没有的了。

    恢复数据字典后,就可以用URL3介绍的方式找出你对应的所有数据库和表的索引ID了。这个时候就遇到为 c_parser 提供数据表建表语句的问题了,这个问题难就难在先有鸡还是先有蛋,一般来说,数据库都被删掉了,哪还有办法去搞出CREATE TABLE 这种建表语句呢?好就好在我们用的是django,它对数据迁移的完美支持救了我一命。在这里讲一句题外话,使用类似django/ror/laravel等有数据迁移框架在此就看出多么重要了。只要在根据原有项目做一次migrate,数据表就建好了,这时候只要用mysqldump导出对应表的建表语句即可:

    mysqldump --add-drop-table=0 --add-lock=0 -d DBNAME TABLENAME -uroot -p > xxxx.sql

    因为c_parser 非常弱,只处理CREATE TABLE 语句,多一点干扰都不行,所以上面的参数都是必要的。

    接下来就是参考URL1把某一个表的数据恢复出来,这里有一个坑,URL1里说把数据恢复到dump.tsv里,其实是不对的,这里应该用dumps/default/TABLENAME,别问我为什么知道,我不会告诉你我找这个原因找瞎了眼,好吧,跟你说,因为生成的load_cmd.sql 里直接引用 dumps/default/TABLENAME,无法设置。所以最后我们这里可用的命令是:

    ./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000002410.page -t xxxx.sql > dumps/default/TABLENAME 2> load_cmd.sql

    把数据恢复出来以后,执行

    mysql --local-infile -uroot -p DBNAME < load_cmd.sql

    就可以把数据导进去了,记得在数据库里查询一下有没有成功,如果没有数据恢复出来,应该是其中的某些环节出了问题。

    这样就成功恢复了某一个表,只要按这里最后三条命令(导出建表语句、恢复数据、导入数据)重复地做下去,你就能把基本上所有的数据都恢复出来了。之所以说是“基本上”,原因是我系统中使用了utf8mb4 编码(为了兼容emoji),结果是如果数据中有emoji的内容就会在导入数据的环节出错,暂时没有找到办法恢复这个数据。

    以上就是整个恢复过程,枯燥、压力山大,这种事情我不想再经历了。如果你也遇到这样的数据恢复需求,希望这篇笔记能够帮到你。但也不要指望我能帮到你更多了,我的经验也仅止于此,天大地大,就此别过,不要找我。谢谢!

    展开全文
  • 开启mysqlbinlog日志后,平时我们操作的sql语句例如增改查,都会记录到日志文件中,如果我们误删某条记录、数据表、数据库,只要我们合理的使用mysqlbinlog,都能对其进行恢复。 二、开启mysqlbinlog 2.1 查看...

    一、关于mysqlbinlog

    mysqlbinlog是数据库的二进制文件,开启mysqlbinlog日志后,平时我们操作的sql语句例如增删改,都会被记录到日志文件中,如果我们误删某条记录数据表数据库,只要我们合理的使用mysqlbinlog,都能对其进行恢复。

    二、开启mysqlbinlog

    2.1 查看是否开始mysqlbinlog
    mysql> show variables like 'log_%';
    +----------------------------------------+----------------------------------+
    | Variable_name                          | Value                            |
    +----------------------------------------+----------------------------------+
    | log_bin                                | ON                               |
    | log_bin_basename                       | /www/server/data/mysql-bin       |
    | log_bin_index                          | /www/server/data/mysql-bin.index |
    | log_bin_trust_function_creators        | OFF                              |
    | log_bin_use_v1_row_events              | OFF                              |
    | log_error                              | ./VM_0_10_centos.err             |
    | log_output                             | FILE                             |
    | log_queries_not_using_indexes          | OFF                              |
    | log_slave_updates                      | OFF                              |
    | log_slow_admin_statements              | OFF                              |
    | log_slow_slave_statements              | OFF                              |
    | log_throttle_queries_not_using_indexes | 0                                |
    | log_warnings                           | 1                                |
    +----------------------------------------+----------------------------------+
    13 rows in set (0.00 sec)
    
    
    2.2 开启mysqlbinlog

    windows开启方式:

    mysql配置文件中新增

    log-bin=D:\phpStudy\PHPTutorial\MySQL\data    //这是保存mysqlbinlog日志的路径
    binlog-format=mixed  
    

    linux开启方式:

    mysql配置文件中新增

    log-bin=mysql-bin
    binlog_format=mixed
    

    其中,mysqlbinlog的三个参数及含义:

    参数名 含义
    Row 日志中会记录成每一行数据被修改的形式,会产生大量的日志数据
    Statement 日志中每条数据被修改后就才会被记录到日志里 ,弥补了Row的不足
    mixed 两者相结合的形式,根据实际场景来进行相应的记录,减少I/O消耗,增加性能

    mysqlbinlog三个参数更详细的介绍

    2.3 重启mysql服务

    三、恢复数据前的数据准备

    3.1 选择一个数据库
    mysql> show databases;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | RedLetter          |
    | RedPacket          |
    | bishe              |
    | brushorder         |
    | caipiao            |
    | daijia             |
    | dht                |
    | linmaocheng        |
    | ljk                |
    | mysql              |
    | mytool             |
    | performance_schema |
    | smallfox           |
    | studyfast          |
    | yuerjia            |
    +--------------------+
    16 rows in set (0.00 sec)
    

    使用dht这个数据库:

    mysql> use dht
    Database changed
    
    3.2 选择一个数据表
    mysql> show tables;
    +---------------+
    | Tables_in_dht |
    +---------------+
    | content       |
    | user          |
    +---------------+
    2 rows in set (0.00 sec)
    

    使用user表进行测试:

    mysql> select * from user;
    +----+-----------+--------+
    | id | name      | pwd    |
    +----+-----------+--------+
    |  1 | 小王      | 123    |
    |  2 | username  | 123456 |
    |  3 | root      | 123456 |
    |  4 | 侯亮平    | 123456 |
    +----+-----------+--------+
    4 rows in set (0.00 sec)
    
    3.3 添加一条测试数据
    mysql> insert into user(name,pwd) values('光头强',123321);
    Query OK, 1 row affected (0.00 sec)
    

    查看是否添加上:

    mysql> select * from user;
    +----+-----------+--------+
    | id | name      | pwd    |
    +----+-----------+--------+
    |  1 | 小王      | 123    |
    |  2 | username  | 123456 |
    |  3 | root      | 123456 |
    |  4 | 侯亮平    | 123456 |
    |  5 | 光头强    | 123321 |
    +----+-----------+--------+
    5 rows in set (0.00 sec)
    
    3.4 删除刚刚添加的测试数据
    mysql> delete from user where id = 5;
    Query OK, 1 row affected (0.00 sec)
    

    查看是否删除成功:

    mysql> select * from user;
    +----+-----------+--------+
    | id | name      | pwd    |
    +----+-----------+--------+
    |  1 | 小王      | 123    |
    |  2 | username  | 123456 |
    |  3 | root      | 123456 |
    |  4 | 侯亮平    | 123456 |
    +----+-----------+--------+
    4 rows in set (0.00 sec)
    

    发现光头强这条数据已经没有了,下面就进行数据恢复。

    四、进行数据恢复

    查看最近的操作被保存到哪个日志里面去了:show master status;

    mysql> show master status;
    +------------------+----------+--------------+------------------+-------------------+
    | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
    +------------------+----------+--------------+------------------+-------------------+
    | mysql-bin.000038 |      688 |              |                  |                   |
    +------------------+----------+--------------+------------------+-------------------+
    1 row in set (0.00 sec)
    

    查看日志偏移信息:show binlog events in 'mysql-bin.000038';

    mysql> show binlog events in 'mysql-bin.000038';
    +------------------+-----+-------------+-----------+-------------+------------------------------------------------------------------+
    | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                             |
    +------------------+-----+-------------+-----------+-------------+------------------------------------------------------------------+
    | mysql-bin.000038 |   4 | Format_desc |         1 |         120 | Server ver: 5.6.44-log, Binlog ver: 4                            |
    | mysql-bin.000038 | 120 | Query       |         1 |         197 | BEGIN                                                            |
    | mysql-bin.000038 | 197 | Intvar      |         1 |         229 | INSERT_ID=5                                                      |
    | mysql-bin.000038 | 229 | Query       |         1 |         354 | use `dht`; insert into user(name,pwd) values('光头强',123321)    |
    | mysql-bin.000038 | 354 | Query       |         1 |         432 | COMMIT                                                           |
    | mysql-bin.000038 | 432 | Query       |         1 |         509 | BEGIN                                                            |
    | mysql-bin.000038 | 509 | Query       |         1 |         610 | use `dht`; delete from user where id = 5                         |
    | mysql-bin.000038 | 610 | Query       |         1 |         688 | COMMIT                                                           |
    +------------------+-----+-------------+-----------+-------------+------------------------------------------------------------------+
    8 rows in set (0.00 sec)
    
    

    在这里插入图片描述
    可以看到Pos为120,End_log_pos为432的偏移量正是插入这条数据的BEGINCOMMIT

    [root@VM_0_10_centos /]# /www/server/mysql/bin/mysqlbinlog  /www/server/data/mysql-bin.000038 --start-position 120 --stop-position 432 | mysql -u root -p dht;
    Enter password: 
    [root@VM_0_10_centos /]#
    

    执行完成后,查看是否已经恢复:

    mysql> select  * from user;
    +----+-----------+--------+
    | id | name      | pwd    |
    +----+-----------+--------+
    |  1 | 小王      | 123    |
    |  2 | username  | 123456 |
    |  3 | root      | 123456 |
    |  4 | 侯亮平    | 123456 |
    |  5 | 光头强    | 123321 |
    +----+-----------+--------+
    5 rows in set (0.00 sec)
    

    我们看到光头强这个测试数据已经恢复了,这个只是恢复数据实战,如果你误删数据表或者数据库,同样可以用此方法进行恢复,找到对应的偏移量即可。

    五、总结

    • 如果偏移量过大的话,可以把日志文件下载下来进行搜索建表建库时候的sql语句,方便查询对应的偏移量进行恢复。
    • 如果,你删了一个库,那这个偏移量是很大的,你只需要找到对应的偏移量,不需要担心恢复之前删掉别的表的数据,毕竟负负得正嘛。
    • 找到相应的偏移量非常重要,只有精准的找到需要恢复的数据偏移量,我们能够很大程度的减少数据丢失的损失。
    展开全文
  • 最终,再腾讯云团队的协助下,经过7*24小时的努力,找回全部数据,此次事件的数据量规模也是非常大的,具体怎么找回被删数据,我们可以来聊聊数据恢复的几种方法 以mysql为例。 binlog是二进制日志文件,用户记录...
  • 突然传来消息:数据库被删库了!这简直不亚于8级大地震呀;一找原因,服务器宕机造成了数据库数据丢失。于是,通过日志恢复数据的救援开始了。 正文 在数据库开启binlog功能 找到/etc/my.cnf并编辑(没有my.cnf的...
  • 此时少一步操作在恢复数据是就能生意不操作(不知道怎么操作时,最好的操作就是不要乱操作),注意 此时最好先暂停网站,防止继续往该表中插入数据,造成新数据id与被删数据id重合,那时恢复起来可能需要遗弃一些数据...
  • 今天我给大家分享一下binlog数据恢复的几种方法。如果你是数据库管理员,相信通过这节课,可以帮助你快速进行数据恢复。...最近,还真的发生了一起库跑路事件,微盟7*24小时紧急恢复数据,商家...
  • 大家有没有碰到过由于误操作把测试数据库的一张表给删除了,导致测试的数据删除了,然后手足无措...MySql数据恢复主要依赖的是Binlog日志,在之前的文章中也有讲过,大家有兴趣可以去看看,这里简单介绍一下: bin
  • mysql被黑如何恢复

    2017-11-27 03:50:24
    周日数据库服务器数据被删,登录有显示这么一个警告。本人有对数据库做每日定时备份,单所在备份文件夹同样被清理,在不缴纳比特币的情况下如何恢复,紧急!Warning!警告!предупреждение!Your File ...
  • 做到尽可能的恢复数据才是一个程序员的自我修养! 当然,前提是你得提前先开启mysql的bin-log日志,并定期备份! bin-log日志的作用:记录mysql的操作内容 bin-log日志的其他用处:mysql读写分离(主从分离) ...
  • 前提条件:原始的mysql,maridb安装目录没有被删 mysql数据内容存放在/home/mysql/mysql/data 1.其中数据库以文件夹形式存在,例如Student数据库,会有一个相应的/home/mysql/mysql/data/Student文件夹 2.还有一个...
  • 我一直在想,地球上这么多程序员,应该有很多人在团队做项目的时候,出过很大的错误...所以掌握如何在数据库被删之后进行恢复,是很重要的。 MySQL删除数据有很多种方式,你可以删除一条数据,可以删除一张表,也可...
  • 写这篇文章我是非常不情愿的,我现在是在写这篇文章,但是同时我也在恢复我服务器数据库的数据,出这篇文章也是在我的意料之外,由于我正在这件事类,我就出一版这样的mysql.frm.ibd文件数据恢复教程,希望这次教程...
  • 数据被删表的.ibd文件,可以从数据库的备份文件中解压出来。然后我用的是虚拟机上的mysql6.5,看了下自己本地电脑上mysql5.5的data里貌似没有.ibd文件 步骤: 1、进入Linux虚拟机,使用service mysql停止mysql服务...
  • 前提注意:当数据文件删除或者清空 扫描工具不能上传到同一分区 如果只有一个分区则可将工具上传到 /dev/shm 目录。 /dev/shm是内存虚拟目录,写入数据在内存中不落盘,系统重启后/dev/shm 自动清空。 现在...
  • http://linux.sheup.com/linux/40/linux30789.htm http://hi.baidu.com/beibeiboo/blog/item/326391c473b20ba08326ac18.htmlhttp://www.router.net.cn/Article/22101.htmlLinux EXT3下删除MySQL据库数据恢复
  • MySQL的崩溃恢复机制

    2021-04-11 09:49:32
    MySQL为了提高性能,你对它数据行的增、、改操作其实都优先发生在内存(Buffer Pool)中。那你想,假如你update了某些数据,Buffer Pool中的数据页也就会你改成脏数据页。那万一你刚修改完并提交了事物,还没来...
  • MySQL数据覆盖与恢复 原因 在线上部署更新项目过程中需要更改数据表结构,由于导入的sql文件不是最新的,使得原来的数据被数据覆盖,覆盖的表为teacherCourse表。 在原来的数据库设计中并没有进行外键的设计...
  • 影响数据安全的都是极小概率的事件,一旦出现问题,就可能被迫上了热搜,之前微盟数据惨遭删除,程序员库跑路追究,可见保护好数据的重要性。 可见数据丢失会造成整个业务系统停止服务,导致直接的财产损失。 ...
  • 云中沙箱实验“RDS的数据备份和恢复”,教您如何使用阿里云RDS来备份和恢复您的数据库!一、基本概念阿里云关系型数据库(Relational Database Service,简称 RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务。...
  • 我曾遇到某初创互联网企业,因维护人员不规范的备份恢复操作,导致系统表空间文件初始化,上万张表无法读取,花了数小时才抢救回来。 当你发现数据无法读取时,也许并非数据丢失了,可能是 DBMS 找不到描述数据的...
  • mysql被删库、删表、勒索病毒破坏后,因为表文件极易被部分覆盖、损坏,导致用文件恢复工具通常无法恢复出表文件,或者恢复出的表文件内容为乱码,mysql无法正常识别加载,这时需要用mysql碎片扫描工具扫描残存的...
  • 话不多说,文件丢失后无法重启mysql,在网上看到有人说如果文件误删后重启mysql,就无法恢复数据,这可能就是传说中的从库到跑路,害怕的我肝都颤了,后来看mysql日志才发现,原来MySQL目录对于mysql没有权限,...
  • MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是...
  • 没经历过的可能永远不知道他的痛,我们在重装系统、手机升级等时候,备份一下数据总是有好处的,指不定那个操作导致磁盘数据丢失,前些日子库跑路判刑的那位老哥,如果公司有备份的话,也不至于损失几个亿(听说...
  • 如果你把mysql搞崩了…比如我手贱把preformance_shcema表了…相信这回帮到你。 ibd2sdi Oracle 将frm文件的信息及更多信息移动到叫做序列化字典信息(Serialized Dictionary Information,SDI),SDI写在ibd文件...
  • mysql 删除

    2019-10-05 03:01:31
    TRUNCATE和DELETE删数据,表结构还在 DELETE可以带条件删除,TRUNCATE是全部删除 DELETE删除会写日志,TRUNCATE不写 DELETE效率低,数据可以恢复,TRUNCATE效率高,数据不可恢复 如果指定参照完整性的删除规则为...
  • MySQL基本使用

    2020-04-08 23:10:34
    3、连接操作4、数据库操作5、数据表操作6、数据改查7、数据备份与恢复 1、MySQL简介? MySQL是一个关系型数据库管理系统,由瑞典MySQL AB公司开发,后来Sun公司收购,Sun公司后来又Oracle公司收购,目前属于...

空空如也

空空如也

1 2 3
收藏数 52
精华内容 20
关键字:

mysql恢复被删数据

mysql 订阅