通过全备+主从同步恢复被drop的库或表
MySQL 中drop 等高危误操作后恢复方法
实验目的:
- 本次实验以恢复drop操作为例,使用不同方法进行误操作的数据恢复.
方法: - 利用master同步(本文)]
- 伪master+Binlog+同步
- 利用binlog改为realy-log在临时slave更新
- 没有备份怎么恢复被drop的表(利用undrop-for-innodb)
1.环境 - mysql 5.7.23-log
- master db210(192.168.99.210)
- slave db212(192.168.99.212)
- 空闲服务器:db211(192.168.99.211)
- 压力:在做本次实验过程用,使用sysbench同时做读写模拟压力(28thread+10*100000行)
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)
通过全备+主从同步恢复被drop的库或表的更多相关文章
- 通过全备+relaylog同步恢复被drop的库或表【转】
MySQL 中drop 等高危误操作后恢复方法 实验目的: 本次实验以恢复drop操作为例,使用不同方法进行误操作的数据恢复. 方法: 利用master同步 伪master+Binlog+同步 利用b ...
- 通过全备+binlog_server同步恢复被drop的库或表
MySQL 中drop 等高危误操作后恢复方法 实验目的: 本次实验以恢复drop操作为例,使用不同方法进行误操作的数据恢复. 方法: 利用master同步 :伪master+Binlog+同步(本文 ...
- 通过全备+relaylog同步恢复被drop的库或表
MySQL 中drop 等高危误操作后恢复方法 实验目的: 本次实验以恢复drop操作为例,使用不同方法进行误操作的数据恢复. 方法: 利用master同步 伪master+Binlog+同步 利用b ...
- 监控MYSQL主从同步配置中监控从库运行状态的脚本
代码如下: #!/bin/bash #Check MySQL Slave's Runnning Status #Crontab time 00:10 MYSQLPORT=`netstat -na|gr ...
- Mysql主从同步问题汇总
data-1-1主机是master,data-1-2是slave Last_IO_Errno: 1236 slave查看show slave status\G; 显示Last_IO_Errno: 12 ...
- 通过 XtraBackup 实现不停机不锁表搭建主从同步
简介 Xtrabackup是由 Percona 开发的一个开源软件,可实现对 InnoDB 的数据备份,支持在线热备份(备份时不影响数据读写).备份时,Xtrabackup 会将 Master 的 b ...
- Mysql主从同步(1) - 概念和原理介绍 以及 主从/主主模式 部署记录
Mysql复制概念Mysql内建的复制功能是构建大型高性能应用程序的基础, 将Mysql数据分布到多个系统上,这种分布机制是通过将Mysql某一台主机数据复制到其它主机(slaves)上,并重新执行一 ...
- MySQL 主从同步失败,数据表修复
问题描述: 接到报警称一台 MySQL 从库同步失败.登录服务器查看错误日志信息如下: Last_Error: Error 'Incorrect key file for table './bfcc/ ...
- MySQL数据库主从同步实战过程
Linux系统MySQL数据库主从同步实战过程 安装环境说明 系统环境: [root@~]# cat /etc/redhat-release CentOS release 6.5 (Final) ...
随机推荐
- [luogu4265][USACO18FEB]Snow Boots silver
题目大意 求出最少需要丢去多少双靴子才能到达终点. 解法 解法一: 看到数据的范围,非常清楚\(O(n^3)\)能过掉所有的数据,那么我们就果断暴力. 解法二: 比较容易会想到用DP做,我一开始定义\ ...
- 【洛谷P3224】永无乡 并查集+Splay启发式合并
题目大意:给定 N 个点的图,点有点权,初始有一些无向边,现在有 Q 个询问,每个询问支持动态增加一条无向边连接两个不连通的点和查询第 X 个点所在的联通块中权值第 K 大的是哪个点. 题解:学会了平 ...
- 理解for循环
先给大家出一个小题目,看看最终我们的i的值是多少? for(var i=0;i<10;i+=2){ if(i<=5){ i++; continue; }else{ i--; break; ...
- 读入字符串/字符 scanf与getchar/gets区别
1. 读入字符 scanf/getchar:空格.Tab.回车都可以读入.但要以回车作为结束符. 所以当读入字符时,注意去掉一些干扰输入的字符,如空格和回车 2. 读入字符串 scanf:不能读入空格 ...
- HTML:<input type="text">文本框不可编辑的方式
1.<input type="text" name="name" value="姓名" disabled /> 该方式显示的文本 ...
- PHP iconv 解决utf-8和gb2312编码转换问题
就一个很简单的函数iconv();但是就是这个函数在网上找了很多例子,都无法成功转换,这是为什么呢? 终于皇天不负有心人,答案还是让我找到了. 网上的都是这样用的 <?php $co ...
- org.apache.catalina.LifecycleException: Failed to stop component(生命周期异常)
真是郁闷透顶,以前昨天还可以用,换了myeclipse自带的tomcat就可以用: 异常: org.apache.catalina.LifecycleException: Failed to stop ...
- Kafka工作原理解析以及主要配置详解
Kafka工作原理解析以及主要配置详解 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 无论是是Kafka集群,还是producer和consumer都依赖于Zookeeper集群保 ...
- 版本控制工具Git工具快速入门-Linux篇
版本控制工具Git工具快速入门-Linux篇 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.版本管理系统的介绍 1>.版本管理系统的特点 1.1>.自动生成备份: ...
- java日期相关
JAVA中获得一个月最大天数的方法 参考博客:http://www.cnblogs.com/relucent/p/4566582.html Calendar 类是一个抽象类,为日历字段之间的转换提供了 ...