当前位置:   article > 正文

mysql恢复误删除的表(drop table)_mysql-bin.000046

mysql-bin.000046

一 试验介绍

备份策略:使用xtrabackup做全量备份

生产服务器:192.168.1.202

恢复服务器:192.168.1.203

想要恢复生产最近被drop的表dba.t4

二 试验步骤

2.1 找到drop table所在binlog

根据用户反馈的故障时间点及相关人员误操作的时间点,确定有可能包含drop 该table的binlog。

这里定位到了三个binlog:

-rw-r-----. 1 mysql mysql   697 Mar 21 11:22 mysql-bin.000044

-rw-r-----. 1 mysql mysql   697 Mar 21 11:23 mysql-bin.000045

-rw-r-----. 1 mysql mysql   831 Mar 21 11:25 mysql-bin.000046

 

#将binlog转换为可读模式

[root@pc1 binlog]# mysqlbinlog -v mysql-bin.000044 > 44.log

[root@pc1 binlog]# mysqlbinlog -v mysql-bin.000045 > 45.log

[root@pc1 binlog]# mysqlbinlog -v mysql-bin.000046 > 46.log

 

#查找包含drop table dba.t4的binlog是哪一个

[root@pc1 binlog]# cat 44.log | grep 'DROP TABLE' | grep 't4'

[root@pc1 binlog]# cat 45.log | grep 'DROP TABLE' | grep 't4'

[root@pc1 binlog]# cat 46.log | grep 'DROP TABLE' | grep 't4'

DROP TABLE `t4` /* generated by server */

说明在mysql-bin.000046中。

 

#查找其对应position

less 46.log

# at 394

#200321 11:24:05 server id 1  end_log_pos 459 CRC32 0xdbd9f265  GTID    last_committed=0        sequence_number=1       rbr_only=no

SET @@SESSION.GTID_NEXT= '6b3c9713-6916-11ea-87dd-080027040516:6'/*!*/;

# at 459

#200321 11:24:05 server id 1  end_log_pos 572 CRC32 0x53ebd65a  Query   thread_id=2     exec_time=0     error_code=0

use `dba`/*!*/;

SET TIMESTAMP=1584761045/*!*/;

SET @@session.pseudo_thread_id=2/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1436549152/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C utf8 *//*!*/;

SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

DROP TABLE `t4` /* generated by server */

2.2 在恢复机器上进行恢复

2.2.1 使用备份进行恢复

需要将备份文件拷贝到恢复机器上进行恢复,以免影响线上环境。

#将备份服务器上的备份数据打包并拷贝到恢复服务器上:

tar czf backup.tar.gz 2020-03-21_11-10-52

scp backup.tar.gz 192.168.1.203:/download/bak/xtrbak/

 

#在恢复机器上执行prepare:

tar xf backup.tar.gz

innobackupex --apply-log /download/bak/xtrbak/2020-03-21_11-10-52

如果最后输出completed ok,则表明数据达到一致状态。

 

#在恢复机器上进行恢复

service mysqld stop

将数据目录设置为空:

cd /data/server/mysql_3307/

mv data data_bak

在恢复机器上恢复数据:

innobackupex --copy-back /download/bak/xtrbak/2020-03-21_11-10-52

chown -R mysql:mysql data

此时,数据恢复到了备份时刻的状态。

service mysqld start

2.2.2 利用备份之后的binlog继续恢复

#将备份后的binlog拷贝到恢复机器上

[root@pc1 xtrbak]# cat 2020-03-21_11-10-52/xtrabackup_binlog_info

mysql-bin.000044 394  2daff865-67ce-11ea-874e-080027040516:1-14,

6b3c9713-6916-11ea-87dd-080027040516:1-3,

a4ac8cd2-e17c-11e9-a602-080027040516:1-89,

d4388817-6914-11ea-bc56-080027040516:1-8,

d4d2f1d2-66f2-11ea-972a-080027040516:1-17,

fa0fb1c5-6912-11ea-a627-080027040516:1-5

因此这里需要拷贝mysql-bin.000044,mysql-bin.000045,mysql-bin.000046

scp mysql-bin.000044 mysql-bin.000045 mysql-bin.000046 192.168.1.203:/download/

 

/usr/local/mysql/bin/mysqlbinlog mysql-bin.000044 --start-position=394 --skip-gtids=true  | mysql -u root -p

/usr/local/mysql/bin/mysqlbinlog mysql-bin.000045 --skip-gtids=true  | mysql -u root -p

/usr/local/mysql/bin/mysqlbinlog mysql-bin.000046 --stop-position=459 --skip-gtids=true  | mysql -u root -p

2.2.3 将恢复后的表导出

mysqldump -u root -p --single-transaction dba t4 -S /tmp/mysql.sock > t4.bak

scp t4.bak 192.168.1.202:/download/

2.3 将表恢复到生产环境

mysql -u root -p dba < t4.bak

 

声明:本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号