MySQL误操作后的数据恢复-低调大师

MySQL误操作后的数据恢复

2016-07-15 617

一、开启binlog。

首先查看binlog是否开启

mysql> show variables like "log_bin";
+---------------+-------+
|Variable_name | Value 
+---------------+-------+
| log_bin     OFF   
+---------------+-------+
1 row in set (0.00 sec)

值为OFF，需开启，开启binlog方式如下：

#vim /etc/my.cnf

在[mysqld]中加入

log-bin                 = mysql-bin
log-bin                 = /usr/local/mysql/log/mysql-bin.log

重启mysql服务

#service mysqld stop
#service mysqld start

二、模拟数据写入

建库

create database backup;

建表

CREATE TABLE `number` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',
  `updatetime` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

写入数据

程序2-1

#coding:utf8
#python2.7
import MySQLdb
import time
def connect_mysql(db_host="192.168.11.169",user="martin",passwd="martin",db="backup",charset="utf8"):
    conn = MySQLdb.connect(host=db_host,user=user,passwd=passwd,db=db,charset=charset)
    conn.autocommit(True)
return conn.cursor()
#数据插入
for i in range(0,10):
    sql = 'insert into number(updatetime) values(%s)'
    values = [(time.strftime("%Y-%m-%d %H:%M:%S"))]
    db1 = connect_mysql()
    print db1.executemany(sql,values)

查询数据

mysql> select * from number;
+-------+------------------------+
| id  | updatetime          
+--------------------------------+
|  1 | 2016-06-29 23:27:15 |
|  2 | 2016-06-29 23:27:15 |
|  3 | 2016-06-29 23:27:15 |
|  4 | 2016-06-29 23:27:15 |
|  5 | 2016-06-29 23:27:15 |
|  6 | 2016-06-29 23:27:15 |
|  7 | 2016-06-29 23:27:15 |
|  8 | 2016-06-29 23:27:15 |
|  9 | 2016-06-29 23:27:15 |
|  10 | 2016-06-29 23:27:15 |
+-------+------------------------+
10 rows in set (0.00 sec)

三、全量备份

mysqldump -uroot -p -F --master-data=2  backup |gzip> /martin/data/backup_$(date +%F).sql.gz

注：加-F能刷新binlog，方便恢复时操作。这篇文章只考虑了一库一表的情况，如有一库多表的情况，可以采用分表备份的策略。

四、模拟写入增量数据

继续执行程序2-1。

查询数据

mysql> select * from number;
+----+---------------------------+
| id  | updatetime          |
+----+---------------------------+
|  1  | 2016-06-29 23:27:15 |
|  2  | 2016-06-29 23:27:15 |
|  3  | 2016-06-29 23:27:15 |
|  4  | 2016-06-29 23:27:15 |
|  5  | 2016-06-29 23:27:15 |
|  6  | 2016-06-29 23:27:15 |
|  7  | 2016-06-29 23:27:15 |
|  8  | 2016-06-29 23:27:15 |
|  9  | 2016-06-29 23:27:15 |
|  10  | 2016-06-29 23:27:15 |
|  11  | 2016-06-29 23:31:03 |
|  12  | 2016-06-29 23:31:03 |
|  13  | 2016-06-29 23:31:03 |
|  14  | 2016-06-29 23:31:03 |
|  15  | 2016-06-29 23:31:03 |
|  16  | 2016-06-29 23:31:03 |
|  17  | 2016-06-29 23:31:03 |
|  18  | 2016-06-29 23:31:03 |
|  19  | 2016-06-29 23:31:03 |
|  20  | 2016-06-29 23:31:03 |
+-------+---------------------+
20 rows in set (0.00 sec)

五、增量备份

保留mysql-bin.000002及之后的binlog即可。

六、模拟误操作

delete from number;

七、再次写入增量数据

执行程序2-1

select * from bumber;

+------+------------------------+
| id | updatetime          |
+------+------------------------+
| 21 | 2016-06-29 23:41:06 |
| 22 | 2016-06-29 23:41:06 |
| 23 | 2016-06-29 23:41:06 |
| 24 | 2016-06-29 23:41:06 |
| 25 | 2016-06-29 23:41:06 |
| 26 | 2016-06-29 23:41:06 |
| 27 | 2016-06-29 23:41:06 |
| 28 | 2016-06-29 23:41:06 |
| 29 | 2016-06-29 23:41:06 |
| 30 | 2016-06-29 23:41:06 |
+------+------------------------+
10 rows in set (0.00 sec)

八、恢复

此时发现之前的delete操作为误操作，急需恢复，恢复过程如下

给该表加上读锁（执行这条语句的窗口在恢复全程不能关闭）

lock table number read;

将全量备份的数据导入

#cd /martin/data/
#gzip -d number_2016-06-29.sql.gz
#grep -i "change" *.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=107;

刷新日志

#mysqladmin -uroot -p'martin' flush-logs
#cd /usr/local/mysql/log
#ls|grep mysql-bin|grep -v index
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003

可确定mysql-bin.000002为增量数据binlog

导入全量备份

#cd /martin/data/
#mysql -uroot -p backup < number_2016-06-29.sql
#cp /usr/local/mysql/log/mysql-bin.000002 /martin/data/
#mysqlbinlog  mysql-bin.000002 >bin.sql
#vim bin.sql

在bin.sql找到之前的delete语句，删除

mysql -uroot -p <bin.sql

九、确认已恢复数据

登录mysql

#mysql -uroot -p'martin' backup
select * from number;

+----+---------------------+
| id | updatetime          |
+----+---------------------+
| 1  | 2016-06-29 23:27:15 |
| 2  | 2016-06-29 23:27:15 |
| 3  | 2016-06-29 23:27:15 |
| 4  | 2016-06-29 23:27:15 |
| 5  | 2016-06-29 23:27:15 |
| 6  | 2016-06-29 23:27:15 |
| 7  | 2016-06-29 23:27:15 |
| 8  | 2016-06-29 23:27:15 |
| 9  | 2016-06-29 23:27:15 |
| 10  | 2016-06-29 23:27:15 |
| 11  | 2016-06-29 23:31:03 |
| 12  | 2016-06-29 23:31:03 |
| 13  | 2016-06-29 23:31:03 |
| 14  | 2016-06-29 23:31:03 |
| 15  | 2016-06-29 23:31:03 |
| 16  | 2016-06-29 23:31:03 |
| 17  | 2016-06-29 23:31:03 |
| 18  | 2016-06-29 23:31:03 |
| 19  | 2016-06-29 23:31:03 |
| 20  | 2016-06-29 23:31:03 |
| 21  | 2016-06-29 23:41:06 |
| 22  | 2016-06-29 23:41:06 |
| 23  | 2016-06-29 23:41:06 |
| 24  | 2016-06-29 23:41:06 |
| 25  | 2016-06-29 23:41:06 |
| 26  | 2016-06-29 23:41:06 |
| 27  | 2016-06-29 23:41:06 |
| 28  | 2016-06-29 23:41:06 |
| 29  | 2016-06-29 23:41:06 |
| 30  | 2016-06-29 23:41:06 |
+----+---------------------+
30 rows in set (0.00 sec)

恢复完成！

微信关注我们

原文链接：https://blog.51cto.com/529876181/1826896

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

zabbix如何监控WEB应用性能

HTTP服务目前最流行的互联网应用之一，如何监控服务的健康状态对系统运维来说至关重要。 Zabbix本身提供了对WEB应用程序的监控，比如监控WEB程序的Download Speed,Response Time和Response Code等性能指标，但是配置起来比较繁琐和复杂。下面通过 python pycurl模块来获取HTTP响应时间，下载速度，状态吗等性能指标。然后通过zabbix trapper的方式来监控WEB应用的性能。 Zabbix trapper监控是客户端收集监控数据，然后以zabbix_sender的方式发送给zabbix server或者proxy服务器。发送的数据主要包括zabbix server或者proxy主机名，监控项和值。zabbix_sender具体用法如下： [root@monitor]#/usr/local/zabbix/bin/zabbix_sender-help ZabbixSenderv2.2.3(revision44105)(7April2014) usage:zabbix_sender[-Vhv]{[-zpsI]-ko|[-zpI]-T-...

2016-07-15

704

在本地缓存中，最常用的就是OSCache和谷歌的Guava Cache。其中OSCache在07年就停止维护了，但它仍然被广泛的使用。谷歌的Guava Cache也是一个非常优秀的本地缓存，使用起来非常灵活，功能也十分强大，可以说是当前本地缓存中最优秀的缓存框架之一。之前我们分析了OSCache的部分源码，本篇就通过Guava Cache的部分源码，来分析一下Guava Cache的实现原理。在分析之前，先弄清数据结构的使用。之前的文章提到，OSCache使用了一个扩展的HashTable，作为缓存的数据结构，由于在get操作上，没有使用同步的方式，通过引入一个更新状态数据结构，来控制并发访问的安全。Guava Cache也是使用一个扩展的HashTable作为其缓存数据结构，然而，在实现上，和OSCache是完全不同的。Guava Cache所用的HashTable和ConcurrentHashMap十分相似，通过引入一个Segment数组，对HashTable进行分段，通过分离锁、final以及volatile的配合，实现了并发环境下的线程安全，同时，性能也非常高（每个Segm...

2016-07-17

716

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。