通过全备+主从同步恢复被drop的库或表

通过全备+主从同步恢复被drop的库或表

MySQL 中drop 等高危误操作后恢复方法

实验目的:

2.本实验的前置条件:

  • 在drop前至少有一次全量备份
  • 从全备到drop操作时间点有全程binlog,并且binlog format=’row’
    如果没有以上两个备份怎么办?见《无备份的误操作恢复方法》

3.模拟误操作

root@localhost [wenyz]>select count(*) from t2; +----------+ | count(*) | +----------+ | 163818 | +----------+ 1 row in set (0.12 sec) root@localhost [wenyz]>drop table t2; Query OK, 0 rows affected (0.02 sec) root@localhost [wenyz]>show master status; +------------------+-----------+--------------+------------------+------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+-----------+--------------+------------------+------------------------------------------------+ | mysql-bin.000020 | 136445791 | | | 9e912d2b-92f6-11e8-9747-0050568be82c:1-9872111 | +------------------+-----------+--------------+------------------+------------------------------------------------+ 1 row in set (0.00 sec) root@localhost [wenyz]>flush logs; Query OK, 0 rows affected (1.41 sec)

4.在实验不同方法之前先完成以下步骤:

  • 复制全备份和所有binlog文件到空闲服务器:db211上
  • 以全备恢复到一个临时新实例(临时slave).

5.找到误操作的位置(GTID或binlog pos)

 通过查找怀疑的binlog: [root@db210_19:11:07 /data/57mysql/mysql3506/logs] #ll total 75564544 -rw-r----- 1 mysql mysql 177 Jul 29 14:14 mysql-bin.000001 ... -rw-r----- 1 mysql mysql 39336996 Jul 29 19:12 mysql-bin.000020 -rw-r----- 1 mysql mysql 13340 Jul 29 19:12 mysql-bin.index [root@db210_19:12:48 /data/57mysql/mysql3506/logs] binlog文件导出命令: #mysqlbinlog -v --base64-output=auto /data/57mysql/mysql3506/logs/mysql-bin.000020 >/data/backup/20.sql binlog文件导出后查找:DROP TABLE `t2`: 在mysql-bin.000020中找到对应位置: # at 97871478 #180731 19:33:29 server id 1853506 end_log_pos 97871543 CRC32 0x8cd4354d GTID last_committed=205567 sequence_number=205570 rbr_only=no original_committed_timestamp=0 immediate_commit_timestamp=0 transaction_length=0 # original_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST) # immediate_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST) /*!80001 SET @@session.original_commit_timestamp=0*//*!*/; SET @@SESSION.GTID_NEXT= '9e912d2b-92f6-11e8-9747-0050568be82c:9791090'/*!*/; # at 97871543 #180731 19:33:29 server id 1853506 end_log_pos 97871660 CRC32 0x974a86d8 Query thread_id=35 exec_time=0 error_code=0 use `wenyz`/*!*/; SET TIMESTAMP=1533036809/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; DROP TABLE `t2` /* generated by server */ /*!*/; # at 97871660 #180731 19:33:29 server id 1853506 end_log_pos 97871725 CRC32 0xb85257d6 GTID last_committed=205567 sequence_number=205571 rbr_only=yes original_committed_timestamp=0 immediate_commit_timestamp=0 transaction_length=0 /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; # original_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST) # immediate_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST) /*!80001 SET @@session.original_commit_timestamp=0*//*!*/; SET @@SESSION.GTID_NEXT= '9e912d2b-92f6-11e8-9747-0050568be82c:9791091'/*!*/; # at 97871725

6.恢复方法一:

  • 构建主的从库,并通过:start slave sql_thread until sql_before_gtids=’9e912d2b-92f6-11e8-9747-0050568be82c:9791090′ 试设置SQL回放位置停在drop操作前一个事务.
  • Executed_Gtid_Set应该停在: 9e912d2b-92f6-11e8-9747-0050568be82c:1-9791089
change master to master_host='db210',master_port=3506,master_user='wyz',master_password='xxxx',master_auto_position=1; root@localhost [(none)]>start slave io_thread ; Query OK, 0 rows affected (0.01 sec) root@localhost [(none)]>show slave status\G; *************************** 1. row *************************** Slave_IO_State: Queueing master event to the relay log Master_Host: db210 Master_User: wyz Master_Port: 3506 Connect_Retry: 60 Master_Log_File: mysql-bin.000015 Read_Master_Log_Pos: 10476294 Relay_Log_File: relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 0 Relay_Log_Space: 27669048 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1853506 Master_UUID: 9e912d2b-92f6-11e8-9747-0050568be82c Master_Info_File: /data/57mysql/mysql3506/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 9e912d2b-92f6-11e8-9747-0050568be82c:6730274-6788383 Executed_Gtid_Set: 9e912d2b-92f6-11e8-9747-0050568be82c:1-6730273 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) ERROR: No query specified root@localhost [(none)]> root@localhost [(none)]>start slave sql_thread until sql_before_gtids='9e912d2b-92f6-11e8-9747-0050568be82c:9791090'; Query OK, 0 rows affected (0.00 sec)
  • 查看sql_thread 执行位置停在9791089
root@localhost [(none)]>show slave status\G; *************************** 1. row *************************** Slave_IO_State: Queueing master event to the relay log Master_Host: db210 Master_User: wyz Master_Port: 3506 Connect_Retry: 60 Master_Log_File: mysql-bin.000079 Read_Master_Log_Pos: 15969193 Relay_Log_File: relay-bin.000024 Relay_Log_Pos: 97871691 Relay_Master_Log_File: mysql-bin.000020 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 97871478 Relay_Log_Space: 15602695666 Until_Condition: SQL_BEFORE_GTIDS Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1853506 Master_UUID: 9e912d2b-92f6-11e8-9747-0050568be82c Master_Info_File: /data/57mysql/mysql3506/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 9e912d2b-92f6-11e8-9747-0050568be82c:6730274-42357224 Executed_Gtid_Set: 9e912d2b-92f6-11e8-9747-0050568be82c:1-9791089 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) ERROR: No query specified root@localhost [(none)]> 
  • 查看数据是否和drop相同:
root@localhost [(none)]>select count(*) from wenyz.t2; +----------+ | count(*) | +----------+ | 163818 | +----------+ 1 row in set (0.10 sec) root@localhost [(none)]>
  • 将数据表导出
/usr/local/mysql57/bin/mysqldump -S /tmp/mysql3506.sock -pxxxx --master-data=2 --single-transaction wenyz t2 >/data/backup/t2.sql
  • 将t2.sql传回master 并导入
[root@db211_20:49:35 /root]  
#scp /data/backup/t2.sql db210:/data/backup/
t2.sql                    
[root@db211_20:50:10 /root]
#/usr/local/mysql57/bin/mysql -S /tmp/mysql3506.sock -pxxxx <t2.sql 
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@db210_21:01:36 /data/backup]  
#fg
/usr/local/mysql57/bin/mysql --login-path=p3506 (wd: /tmp)
root@localhost [wenyz]>select count(*) from t2;
+----------+
| count(*) |
+----------+
|   163818 |
+----------+
1 row in set (0.40 sec)

转载于:https://www.cnblogs.com/2woods/p/9394614.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/101517.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • 5种常见的运行时异常_五种常见异常

    5种常见的运行时异常_五种常见异常五种常见的运行时异常空指针异常 NullPointerException数组越界异常 IndexOutOfBoundsException类转换异常 ClassCaseException向数组中存放与声明类型不兼容对象异常ArrayStoreException…

  • 安装Wamp后 Apache无法启动的解决方法

    安装Wamp后 Apache无法启动的解决方法

  • 交互式脚本_交互式和脚本式的区别

    交互式脚本_交互式和脚本式的区别带你打开脚本的大门,领略语言之美

  • mongovue查询字段_mongodb查询速度

    mongovue查询字段_mongodb查询速度{“ei”:”AW4BROILANDSTART1″,//条件一”cd”:{$elemMatch:{“0004″:{$gte:0}}}, //条件二,cd为集合,0004为集合中的key”st”:{$gte:ISODate(“2013-09-05T00:00:00.958Z”)}//时间条件,”im”:{$exists:true},”cn”:{$ne:””},

  • SpringBoot整合Quartz定时任务(持久化到数据库)

    背景最近在做项目,项目中有个需求:需要使用定时任务,这个定时任务需要即时生效。查看Quartz官网之后发现:Quartz提供两种基本作业存储类型:RAMJobStore:RAM也就是内存,默认情况下Quartz会将任务调度存在内存中,这种方式性能是最好的,因为内存的速度是最快的。不好的地方就是数据缺乏持久性,但程序崩溃或者重新发布的时候,所有运行信息都会丢失JDBC作业存储:存到数据库…

  • 数据库泄密 事件_数据库的安全性

    数据库泄密 事件_数据库的安全性知道CSDN用户数据库泄露这件事情是在12月21日晚上八九点的时候,那时候正在整理第二天报告要用到的思维导图,大奎告诉我说CSDN的用户密码都被泄露了,刚开始还不相信,不过当我从网上下载CSDN数据库文件,并看到自己的账户和密码时,我信了,并且心惊了一下,本来想着对自己的密码立刻进行修改,但网站采取了紧急措施,关闭了相应的功能,或许是为了防止别人恶意修改吧.       此次事件在互联网上

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号