引文
人生在世,难免有手滑的时候。没有悄悄咪咪删过表数据的程序员的人生,一定是不完美的。特别是连续加班后,带着昏沉沉的大脑,难免会一个不留神,写下了罪恶的foreach remove语句。满怀信心的一看数据库。啪,快乐没有了!表数据因为不合适的查询条件,进行了全表数据删除的操作!
此时的你一定万分慌张,甚至已经收拾好行李,准备下一秒就提着桶跑路了!
为什么要跑路呢?因为你不知道接下来该如何处理,只能依靠工具猴最原始的自我保护机制,驱使自己前进。
除了跑路,我们还能做些什么呢?!别慌,下面就来讲讲遇到这种情况,我们该如何从容应对。
MysqlBinLog
全文的数据修复基础在于mysql的binlog功能,所以下文会从binlog的原理、使用等几点方面来介绍如何进行数据修复。
什么是MysqlBinLog
binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志。
binlog不会记录SELECT和SHOW这类操作,因为这类操作对数据本身并没有修改,但你可以通过查询通用日志来查看MySQL执行过的所有语句。
binlog可以用于记录mysql的数据变更,数据在恢复的时候binlog日志能起到很大的作用。mysql的主从复制就是利用的binlog原理。
检查MysqlBinLog功能是否开启
因为一切基于binlog日志,所以binlog日志必须处于开启状态下,才会记录开启之后的表结构变更和表数据修改。如果你删数据后发现binlog日志没开且正好又是生产环境,那恭喜你,你基本只能跑路了!
查看
登录mysql后执行以下语句show variables like 'log_%';
从中我们可以看出,binlog并没有处于开启阶段。
开启
查看my.cnf
路径
如果不知道位置,可以执行以下命令/usr/local/mysql/bin/mysql --help --verbose | grep my.cnf
在/etc
新建文件my.cnf
并添加如下内容
[mysqld]
# log_bin
log-bin = mysql-bin #开启binloglc
binlog-format = ROW #选择row模式
server_id = 1 #配置mysql replication需要定义,不能和canal的slaveId重复