精华内容
下载资源
问答
  • emmmmm 今天晚上十一点有个朋友说他的数据库删除了。是昨天删除的。我就日了mmp 了数据库不做备份的??????...那么就新建一个数据库导入进去呗 ...那么就找以后的4月22号以后的数据吧找了一下binlo...

    emmmmm  

    今天晚上十一点有个朋友说他的数据库删除了。是昨天删除的。我就日了mmp 了数据库不做备份的??????????

    what fuck 

    那就登陆服务器看看吧

    看到还有一个4 月22 号的。那么就新建一个数据库导入进去呗

     

    导入

    导入之后改下源代码看看能不能访问

     emmmm 

    可以访问啊。那么就找以后的4月22号以后的数据吧找了一下binlog文件

     

    emmmm发现不全先导出来再说吧

     

    emmm 看一下大小

     

    emmmm 有点懵逼 ,

    朋友说是5月15好有一个小程序很重要,我进去看看 16.sql  mmp 1G的文件 打开贼慢了。

    有点心塞,好像缺少了两天的数据了

     

    那么没有办法了。但是导入1G的东西是不是太多了。减少一点吧。

     

    hhhh 还有700M

     

    进去找到删库的语句吧没办法

     

    7560966 行删除。看看最后一行吧

     

    那么就从 7560966删除到7994269行

     

    还有482M 那么就简单多了!!!

     mysql -uroot -p'cX4NksmixrDmTiSp' yinbin_11  <19.sql

    但是会有错误。我想了。因为这个里面会有其他的数据库和其他的表,那么,直接去掉那个错误就行了

    mysql -uroot -p'cX4NksmixrDmTiSp' -f yinbin_11  <19.sql 

     

     

    然后坐等执行完吧

     

    进入网站看下

     

    然后就回来了。数据无价。请记得备份数据库啊 兄弟!!!!!!!!!

     

     

    转载于:https://www.cnblogs.com/liang2580/p/9074951.html

    展开全文
  • 手贱!一不小心把库删了!

    背景:我把库删了!!还没有备份!!!!!!!

    以下的所有操作,需要基于MySQL的binlog文件。

    如果连binlog文件都没了,就不用继续看下去了。

    环境:Windows 10、MySQL 5.7 还是 8.0 好像都可以

    总之,一定一定定期备份!!同时开启binlog文件!!!

     

    具体思路

    0. 冷静。立即终止所有数据库的操作。找到binlog文件。

    1. 把binlog文件,恢复成SQL。

    2. 执行SQL文件,恢复数据库。

     

    小技巧(这都是踩了坑以后总结出来的),为了节省时间(不要做无用功)

    1. binlog文件往往很大。如果要恢复特定的库,只需要从binlog中恢复指定库名的SQL文件

    2. 当你拿到一堆binlog日志恢复成SQL的时候,你会发现数据库在本次删除之前可能就有被删除,所以建议把SQL从后往前看,找到最后一次drop的地方,从这里开始往后恢复

    3. 一定不能恢复到你手误drop库的那句话!!!

    默认开启了binlog,每次mysql server 重启,会新建一个binlog。

     

    binlog恢复SQL

    在控制台里执行

    -- 整个bin全部恢复成SQL

    mysqlbinlog.exe D:\MySQL\Data\binlog\mysql-bin.000001 --start-position=0 --stop-position=9999999999999 | mysql -u用户名 -p密码

    如:mysqlbinlog.exe D:\MySQL\Data\binlog\mysql-bin.000001 --start-position=0 --stop-position=9999999999999 | mysql -uroot -proot

    -- stop-position 似乎需要写得大一点,以涵盖整个binlog文件

     

    -- 从某个位置开始恢复成SQL

    mysqlbinlog.exe D:\MySQL\Data\binlog\mysql-bin.000048 --start-position=912903526 --stop-position=9999999999999 | mysql -u用户名 -p密码

     

    -- binlog恢复SQL的时候,选定数据库

    运行mysqlbinlog.exe时,指定数据库,好像是这个参数 --database=db

    mysqlbinlog --no-defaults --database=gildata  --base64-output=decode-rows -v F:/binlog/Data/binlog/mysql-bin.000128 > F:/binlog_output/mysql-bin.000128.sql

     

    导入刚刚恢复的SQL

    mysql -u用户名 -p密码 数据库名 < F:/binlog_output/恢复出来的sql文件

    如:mysql -uroot -proot gildata < F:/binlog_output/mysql-bin.000051.gildata.sql

     

    查看SQL执行进度

    如果SQL特别大,恢复的过程中还想查看SQL的执行进度。

    但这里我就没有更新了…

     

    展开全文
  • 展开全部每个 DBA 是不是都有过删库的经历?删库了没有备份怎么办?备份恢复后无法启动服务什么情况?表定义损e69da5e887aa62616964757a686964616f31333433626437坏数据无法读取怎么办?我曾遇到某初创互联网企业,...

    展开全部

    每个 DBA 是不是都有过删库的经历?删库了没有备份怎么办?备份恢复后无法启动服务什么情况?表定义损e69da5e887aa62616964757a686964616f31333433626437坏数据无法读取怎么办?

    我曾遇到某初创互联网企业,因维护人员不规范的备份恢复操作,导致系统表空间文件被初始化,上万张表无法读取,花了数小时才抢救回来。

    当你发现数据无法读取时,也许并非数据丢失了,可能是 DBMS 找不到描述数据的信息。

    背景

    先来了解下几张关键的 InnoDB 数据字典表,它们保存了部分表定义信息,在我们恢复表结构时需要用到。

    SYS_TABLES 描述 InnoDB 表信息CREATE TABLE `SYS_TABLES` (`NAME` varchar(255) NOT NULL DEFAULT '',  表名`ID` bigint(20) unsigned NOT NULL DEFAULT '0',  表id`N_COLS` int(10) DEFAULT NULL,`TYPE` int(10) unsigned DEFAULT NULL,`MIX_ID` bigint(20) unsigned DEFAULT NULL,`MIX_LEN` int(10) unsigned DEFAULT NULL,`CLUSTER_NAME` varchar(255) DEFAULT NULL,`SPACE` int(10) unsigned DEFAULT NULL,   表空间idPRIMARY KEY (`NAME`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;SYS_INDEXES 描述 InnoDB 索引信息CREATE TABLE `SYS_INDEXES` (  `TABLE_ID` bigint(20) unsigned NOT NULL DEFAULT '0', 与sys_tables的id对应  `ID` bigint(20) unsigned NOT NULL DEFAULT '0',  索引id  `NAME` varchar(120) DEFAULT NULL,         索引名称  `N_FIELDS` int(10) unsigned DEFAULT NULL, 索引包含字段的个数  `TYPE` int(10) unsigned DEFAULT NULL,  `SPACE` int(10) unsigned DEFAULT NULL,  存储索引的表空间id  `PAGE_NO` int(10) unsigned DEFAULT NULL,  索引的root page id  PRIMARY KEY (`TABLE_ID`,`ID`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;SYS_COLUMNS 描述 InnoDB 表的字段信息CREATE TABLE `SYS_COLUMNS` (  `TABLE_ID` bigint(20) unsigned NOT NULL, 与sys_tables的id对应  `POS` int(10) unsigned NOT NULL,     字段相对位置  `NAME` varchar(255) DEFAULT NULL,    字段名称  `MTYPE` int(10) unsigned DEFAULT NULL,  字段编码  `PRTYPE` int(10) unsigned DEFAULT NULL, 字段校验类型  `LEN` int(10) unsigned DEFAULT NULL,  字段字节长度  `PREC` int(10) unsigned DEFAULT NULL, 字段精度  PRIMARY KEY (`TABLE_ID`,`POS`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;SYS_FIELDS 描述全部索引的字段列CREATE TABLE `SYS_FIELDS` (  `INDEX_ID` bigint(20) unsigned NOT NULL,  `POS` int(10) unsigned NOT NULL,  `COL_NAME` varchar(255) DEFAULT NULL,  PRIMARY KEY (`INDEX_ID`,`POS`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;./storage/innobase/include/dict0boot.h 文件定义了每个字典表的 index id,对应 id 的 page 中存储着字典表的数据。e8397ca9f908abcbea4ed61fa2941d0d.png

    这里我们需要借助 undrop-for-innodb 工具恢复数据,它能读取表空间信息得到 page,将数据从 page 中提取出来。

    # wget https://github.com/chhabhaiya/undrop-for-innodb/archive/master.zip# yum install -y gcc flex bison# make# make sys_parser

    # ./sys_parser 读取表结构信息

    sys_parser [-h] [-u] [-p] [-d] databases/table

    stream_parser 读取 InnoDB page 从 ibdata1 或 ibd 或分区表

    # ./stream_parserYou must specify file with -f optionUsage: ./stream_parser -f [-T N:M] [-s size] [-t size] [-V|-g]  Where:    -h         - Print this help    -V or -g   - Print debug information    -s size    - Amount of memory used for disk cache (allowed examples 1G 10M). Default 100M    -T         - retrieves only pages with index id = NM (N - high word, M - low word of id)    -t size    - Size of InnoDB tablespace to scan. Use it only if the parser can't determine it by himself.

    c_parser 从 innodb page 中读取记录保存到文件

    # ./c_parserError: Usage: ./c_parser -4|-5|-6 [-dDV] -f -t table.sql [-T N:M] [-b ]  Where    -f -- InnoDB page or directory with pages(all pages should have same index_id)    -t -- CREATE statement of a table    -o -- Save dump in this file. Otherwise print to stdout    -l -- Save SQL statements in this file. Otherwise print to stderr    -h  -- Print this help    -d  -- Process only those pages which potentially could have deleted records (default = NO)    -D  -- Recover deleted rows only (default = NO)    -U  -- Recover UNdeleted rows only (default = YES)    -V  -- Verbose mode (lots of debug information)    -4  -- innodb_datafile is in REDUNDANT format    -5  -- innodb_datafile is in COMPACT format    -6  -- innodb_datafile is in MySQL 5.6 format    -T  -- retrieves only pages with index id = NM (N - high word, M - low word of id)    -b

    接下来,我们演示场景的几种数据恢复场景。

    场景1:drop table

    是否启用了 innodb_file_per_table 其恢复方法有所差异,当发生误删表时,应尽快停止MySQL服务,不要启动。若 innodb_file_per_table=ON,最好只读方式重新挂载文件系统,防止其他进程写入数据覆盖之前块设备的数据。

    如果评估记录是否被覆盖,可以表中某些记录的作为关键字看是否能从 ibdata1 中筛选出。

    # grep WOODYHOFFMAN ibdata1

    Binary file ibdata1 matches

    也可以使用 bvi(适用于较小文件)或 hexdump -C(适用于较大文件)工具

    以表 sakila.actor 为例CREATE TABLE `actor` (`actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,`first_name` varchar(45) NOT NULL,`last_name` varchar(45) NOT NULL,`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`actor_id`),KEY `idx_actor_last_name` (`last_name`)) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8

    首先恢复表结构信息1. 解析系统表空间获取 page 信息

    ./stream_parser -f /var/lib/mysql/ibdata1

    2. 新建一个 schema,把系统字典表的 DDL 导入

    cat dictionary/SYS_* | mysql recovered

    3. 创建恢复目录

    mkdir -p dumps/default

    4. 解析系统表空间包含的字典表信息,

    ./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql > dumps/default/SYS_TABLES 2> dumps/default/SYS_TABLES.sql./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000002.page -t dictionary/SYS_COLUMNS.sql > dumps/default/SYS_COLUMNS 2> dumps/default/SYS_COLUMNS.sql./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql > dumps/default/SYS_INDEXES 2> dumps/default/SYS_INDEXES.sql./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000004.page -t dictionary/SYS_FIELDS.sql > dumps/default/SYS_FIELDS 2> dumps/default/SYS_FIELDS.sql

    5. 导入恢复的数据字典

    cat dumps/default/*.sql | mysql recovered

    6. 读取恢复后的表结构信息

    ./sys_parser -pmsandbox -d recovered sakila/actor

    由于 5.x 版本 innodb 引擎并非完整记录表结构信息,会丢失 AUTO_INCREMENT 属性、二级索引和外键约束, DECIMAL 精度等信息。

    若是 mysql 5.5 版本 frm 文件被从系统删除,在原目录下 touch 与原表名相同的 frm 文件,还能读取表结构信息和数据。若只有 frm 文件,想要获得表结构信息,可使用 mysqlfrm --diagnostic /path/to/xxx.frm,连接 mysql 会显示字符集信息。

    innodb_file_per_table=OFF

    因为是共享表空间模式,数据页都存储在 ibdata1,可以从 ibdata1 文件中提取数据。

    1. 获取表的 table id,sys_table 存有表的 table id,sys_table 表 index id 是1,所以从0000000000000001.page 获取表 id./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql | grep sakila/actor000000000B28  2A000001430D4D  SYS_TABLES  "sakila/actor"  158  4  1 0   0   ""  0000000000B28  2A000001430D4D  SYS_TABLES  "sakila/actor"  158  4  1 0   0   ""  0

    2. 利用 table id 获取表的主键 id,sys_indexes 存有表索引信息,innodb 索引组织表,找到主键 id 即找到数据,sys_indexes 的 index id 是3,所以从0000000000000003.page 获取主键 id

    ./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql | grep 158000000000B28    2A000001430BCA  SYS_INDEXES     158     376     "PRIMARY"       1       3       0       4294967295000000000B28    2A000001430C3C  SYS_INDEXES     158     377     "idx_actor_last_name"        1       0       0       4294967295000000000B28    2A000001430BCA  SYS_INDEXES     158     376     "PRIMARY"       1       3       0       4294967295000000000B28    2A000001430C3C  SYS_INDEXES     158     377     "idx_actor_last_name"        1       0       0       4294967295

    3. 知道了主键 id,就可以从对应 page 中提取表数据,并生成 sql 文件。

    ./c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000376.page -t sakila/actor.sql > dumps/default/actor 2> dumps/default/actor_load.sql

    4. 最后导入恢复的数据

    cat dumps/default/*.sql | mysql sakila

    更多详细情况点击网页链接

    cfe304d124aafb2e893a01027f1c2bd8.png

    请点击输入图片描述

    展开全文
  • 话不多说,继续数据库的学习:三天前学习了数据库的增删改查。其中对于drop+database+数据库名这个命令记忆尤深,也听教程里的老师再三嘱咐用...也就是说删除了还是可以恢复的呀,既然如此那还怕什么删库跑路……一...

    话不多说,继续数据库的学习:

    a3114eadbd479cda37f2db391872956a.png

    三天前学习了数据库的增删改查。

    其中对于drop+database+数据库名这个命令记忆尤深,也听教程里的老师再三嘱咐用这个命令要切记谨慎处理,否则是要负刑事责任的。

    毕竟互联网公司,最重要的也就是数据了。

    今年年初的时候微盟就发生过程序员删库跑路事件,所以也一直铭记在心。

    结果今天告诉我数据库是可以备份和恢复的?

    也就是说删除了还是可以恢复的呀,既然如此那还怕什么删库跑路……

    一、数据库备份与恢复

    7ad8838baca4a139b07c3a6656c549aa.png

    ①数据库备份

    将数据库student备份到test文件夹下student.sql文件里面。注意test文件夹要存在,不然会报错。

    语法:mysqldump -u 用户名 -p 数据库名 > 磁盘SQL文件路径

    dump,转出、转储的意思,mysqldump也就可以理解成数据库备份。

    由于mysqldump命令不是sql命令,需要在DOS窗口下使用。

    我晕,昨天才刚说用了可视化工具Navicat,再也不用在DOS窗口下输入命令行了。结果又啪啪打自己的脸……

    ②数据库恢复方案一

    这个很简单,就是将备份中的>改成

    语法:mysqldump -u 用户名 -p 数据库名 < 磁盘SQL文件路径

    将备份的文件导入到我自己的数据库里面,同样的道理,该命令也是需要在DOS窗口下使用。

    ③数据库恢复方案二

    该方案是SQL语句,是在数据库中操作,命令如下:source+磁盘SQL文件路径

    source,根源的意思。

    二、表与表之间的关系

    表与表之间一共有三种关系,如下图:

    383b7700a85baa1fe46083d53fb1d1dc.png

    ①1对多

    一个部分有多个成员,一个成员只属于一个部门,所以是1对多。

    ②多对多

    一个程序员会开发多个项目,一个项目会被多个程序员开发,所以是多对多。

    这种情况据说在外包公司中很常见……

    ③1对1

    一个丈夫只能有一个妻子,一个妻子只能有一个丈夫,所以是1对1。

    其中又以一对多和多对多最常见。

    三、一对多表设计

    以上述部门和成员的关系作为例子:

    ae06b961bf3cb4950d434bd3dfb6f109.png

    ①部门表

    一共有三个部门,每个部门有自己对应的id。

    那如何将这两张表联系起来?

    如果是在部门表加入成员表的id,那一行需要添加多个数据,显然不行。

    ②成员表

    一共有七个成员。

    如何将这两张表联系起来?

    每个成员后面添加一个属性,也就是自己对应的部门id,这样就一目了然。

    那么现在问题来了:

    这只是在成员表中做了一个声明,实际上这两张表并没有关联起来。

    具体什么意思呢?

    简单的理解就是:假如将部门表中的某个部门是删除的,但是成员表中的数据还有这个部门。

    想要解决这个问题,就要引用外键约束这个概念,将这两张表真真正正地关联起来。

    如何添加外键约束?

    2110e3e7a54157213b3f6dc7a3a56958.png

    ①建表后添加外键约束

    foreign key即为外键的意思。

    references,参考的意思,这里可以理解成关联。

    也就是说把成员表中的dept_id作为外键,同时与部门表中的id相关联。

    这样的话,你想删除部门表中的某个部门,得保证成员表中没有该部门的成员。

    ②建表时添加外键约束

    一般来说,会在建表的时候就添加外键,格式是一样的。

    其中:

    • 部门表(1对多中的1)也叫主表。
    • 成员表(1对多中的多)也叫从表。

    也就是说想要删除主表中的数据,必须保证从表中和其相关的数据不存在。

    其中一对一表设计和一对多是很相似的,就是任意一张表将另外一张表的id作为外键就可以了。

    操作起来很简单,并且一般应用以一对多和多对多为主,在此就不再赘述了。

    四、多对多表设计

    程序员表和项目表便是多对多的关系。

    写sql语句创建表和添加数据,也算是对这几天学的知识点做一个复习。

    ebea0fee5bae299fe52bbb35d44cda87.png

    ①创建程序员表对表本身的操作,所以有table这个单词。

    create table coder(表字段说明)。

    其中里面表字段之间使用逗号隔开的,最后一个字段又没有逗号。

    我用的分号然后一直报错,弄了半天才发现这个问题,感觉要被自己蠢疯了。②创建项目表

    格式同上。

    ③给程序员表添加数据

    insert into+表名+values+(每列对应的值);

    这是将列名省略了的写法,列名省略了之后再赋值时,每列都得赋值。

    ④给项目表添加数据

    格式也同上。

    那么在多对多的表中是怎么将两张表关联起来的?

    3948a602871361fdb943466e1ed72444.png

    创建一个中间表,将这两个表关联起来。

    • 中间表表名一般会将这两个表名结合起来,见名知意。
    • 中间表有两个外键。
    • 外键分别对应两张表中的主键。

    这样的话,这两张表也就被关联起来了。

    最后

    谢谢你的观看。

    如果可以的话,麻烦帮忙点个赞,谢谢你。

    展开全文
  • 据悉,顺丰科技数据中心的一位邓某因误删生产数据库,导致某项服务无法使用并持续590分钟。事发后,顺丰将邓某辞退,且在顺丰...真实地玩了一把“从删库到跑路”。 毫无疑问地,我们又突然象被打了鸡血般,...
  • 直接贴图,easy 1、指定数据库和表,以及时间节点 2、从扫描的日志,执行回滚语句 至此 。 。 。 。 OJBK,,
  • 在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...
  • 原标题:记一次 MySQL 删库数据恢复来源:赖勇浩,blog.csdn.net/gzlaiyonghao/article/details/53340475昨天因为不可描述的原因,数据库直接被 drop database删除。在第一时间停止数据库服务和Web服务,备份MySQL...
  • 恢复表结构把刚才移走的几个文件又恢复到了原目录里,既然恢复MySQL进程现在没什么希望了,那就想办法恢复数据吧。 进入到数据库目录(/var/lib/mysql)下找到了我的数据库名字以目录的形式存放。 进去该目录以后...
  • Gitlab 也给出了自己的解决方案和未来针对备份的ToDo list 1. 更改服务器终端的颜色来区分生产环境(红色)、测试环境...2. 定期检查数据库备份的目录,查看备份的数据是否成功备份。 3. 添加备份提醒,定
  • 展开全部每个 DBA 是不是都有过删库的经e68a84e8a2ad62616964757a686964616f31333433626437历?删库了没有备份怎么办?备份恢复后无法启动服务什么情况?表定义损坏数据无法读取怎么办?我曾遇到某初创互联网企业,...
  • 在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...
  • 在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...
  • 记一次MySQL删库数据恢复

    万次阅读 2016-11-25 21:43:49
    在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...
  • 在第一时间停止数据库服务和Web服务,备份MySQL数据目录下的所有文件之后,开始走上数据恢复之路。第一次干这种事,各种不得法。因为我们既没有备份,也没有开启binlog,连innodb_file_per_tabe_也没有。一番折腾后...
  • 本文由北亚数据恢复中心(http://www.frombyte.com)张宇所写,如有错误,祝愿各位中秋节删库还跑不了路。 事件回顾: 据悉,顺丰科技数据中心的一位邓某因误删生产数据库,导致某项服务无法使用并持续590分钟。事发后...
  • 展开全部每个 DBA 是不是都有过删库的经历?删库了没有备份怎么办?备份恢复后无法启动服务什么情况?表e5a48de588b63231313335323631343130323136353331333433626437定义损坏数据无法读取怎么办?我曾遇到某初创...
  • 最近有个删库跑路的帖子在网上引起热议,很多企业管理者都开始担忧数据库的安全可靠性。其实是数据库安全和备份机制没做到位,如果一开始就采用严密的安全机制和完善的数据库备份机制,那么即便是误删了数据库也可以...
  • 一次数据库表运维操作误删的数据恢复实践
  • 最近有个删库跑路的帖子在网上引起热议,很多企业管理者都开始担忧数据库的安全可靠性。其实是数据库安全和备份机制没做到位,如果一开始就采用严密的安全机制和完善的数据库备份机制,那么即便是误删了数据库也可以...
  • 年初的微盟删库事件人尽皆知,造成的影响也是很深远的,短时间内公司市值蒸发30港元,赔偿商家1.5亿,造成的其他影响也是很深远的。最终,再腾讯云团队的协助下,经过7*24小时的努力,找回全部数据,此次事件的数据...
  • 1、登录阿里云RDS后台,找到“备份”入口,如下图:2、下载最近的备份数据,如下图:3、解压,找到... 将下载的备份数据中对应的表(第三步中框选的文件) 拷贝到 本地数据库目录中,如下图:PS:若本地中已存在...
  • 每个 DBA 是不是都有过删库的经历?删库了没有备份怎么办?备份恢复后无法启动服务什么情况?表定义损坏数据无法读取怎么办?我曾遇到某初创互联网企业,因维护人员不规范的备份恢复操作,导致系统表空间文件被初始...
  • 最近网上很多同学都在疯传疫情删库=跑路,工作中误删数据或者数据库我们一定需要跑路吗?我看未必在 MySQL数据库中我们知道 binlog 日志记录了我们对数据库的所有操作接下来就来开启程序员自救之路 一、开启Binlog...
  • [mysqld] 下增加vim /etc/my.cnf## 设置 server_id,一般设置为 IPserver_id=8# # 复制过滤:需要备份的数据库,输出 binlogbinlog-do-db=testdb#复制过滤:不需要备份的数据库,不输出(mysql 一般不同步)binlog-...
  • 库恢复 先找到需要恢复的数据,解压出来 gunzip miaosha-202008061026.sql.gz 使用解压出来的文件,将数据恢复到指定的新数据库中 方式一,linux命令行下: mysql -uroot -p db2 < miaosha-202008061026....

空空如也

空空如也

1 2 3 4 5 ... 19
收藏数 361
精华内容 144
关键字:

数据库删库恢复数据