binlog2sql实现mysql的闪回

binlog2sql是大众点评开源的一款用于解析binlog的工具,在测试环境试用了下,还不错。

 DBA或开发人员,有时会误删或者误更新数据,如果是线上环境并且影响较大,就需要能快速回滚。传统恢复方法是利用备份重搭实例,再应用去除错误sql后的binlog来恢复数据。此法费时费力,甚至需要停机维护,并不适合快速回滚。也有团队利用LVM快照来缩短恢复时间,但快照的缺点是会影响mysql的性能。现在有不少好用而且效率又高的开源闪回工具如binlog2sql、mysqlbinlog_flashback,这些工具在工作中给DBA减轻了不少痛苦,以下针对binlog2sql的使用进行实践演练。

1.安装binlog2sql前先安装git和pip

yum -y install epel-release

yum -y install git python-pip

2.安装binlog2sql:

git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql

pip install -r requirements.txt

3.mysql配置文件my.cnf中进行如下配置,并在/var/log/下创建mysql文件夹

[mysqld]

server_id = 1

log_bin = /var/log/mysql/mysql-bin.log

max_binlog_size = 1G

binlog_format = row

binlog_row_image = full

(但你会发现重启Mysqld服务时会报错,于是想到给mysql文件夹一个权限)

chown -R mysql:mysql  /var/log/mysql

4.给予用户授权(此处一定要注意授权的方式)

GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'localhost' identified by '[email protected]';

权限说明:

select:需要读取server端information_schema.COLUMNS表,获取表结构的元信息,拼接成可视化的sql语句

super/replication client:两个权限都可以,需要执行'SHOW MASTER STATUS', 获取server端的binlog列表

replication slave:通过BINLOG_DUMP协议获取binlog内容的权限

5.内网环境如何使用该工具呢?

该工具的使用依赖以下三个包:

PyMySQL==0.7.8

wheel==0.24.0

mysql-replication==0.9

其中,每个包又会依赖其它包,所以安装这些包是一个比较麻烦的事情。

如果是在外网的环境下,可直接通过pip install安装,它会自动下载并安装依赖包的。


在内网环境下,可手动安装这些包,目前,这些包已下载打包,并上传到百度云盘中,大家可自行下载。

http://pan.baidu.com/s/1qYQ2PPy

6.安装教程:

# tar xvf binlog2sql.tar.gz

# cd binlog2sql/binlog2sql_dependencies/

# tar xvf setuptools-0.6c11.tar.gz

# cd setuptools-0.6c11

# python setup.py install

# cd ..

# tar xvf pip-9.0.1.tar.gz

# cd pip-9.0.1

# python setup.py install

# cd ..

# pip install *.whl mysql-replication-0.9.tar.gz

7.至此,所有依赖包安装完毕。

binlog2sql的使用参数说明:

mysql连接配置

-h host; -P port; -u user; -p password

解析模式

--stop-never 持续同步binlog。可选。不加则同步至执行命令时最新的binlog位置。

-K, --no-primary-key 对INSERT语句去除主键。可选。

-B, --flashback 生成回滚语句,可解析大文件,不受内存限制,每打印一千行加一句SLEEP SELECT(1)。可选。与stop-never或no-primary-key不能同时添加。

解析范围控制

--start-file 起始解析文件。必须。

--start-position/--start-pos start-file的起始解析位置。可选。默认为start-file的起始位置。

--stop-file/--end-file 末尾解析文件。可选。默认为start-file同一个文件。若解析模式为stop-never,此选项失效。

--stop-position/--end-pos stop-file的末尾解析位置。可选。默认为stop-file的最末位置;若解析模式为stop-never,此选项失效。

--start-datetime 从哪个时间点的binlog开始解析,格式必须为datetime,如'2016-11-11 11:11:11'。可选。默认不过滤。

--stop-datetime 到哪个时间点的binlog停止解析,格式必须为datetime,如'2016-11-11 11:11:11'。可选。默认不过滤。

对象过滤

-d, --databases 只输出目标db的sql。可选。默认为空。

-t, --tables 只输出目标tables的sql。可选。默认为空。


13760069-5669df37389f54c1.PNG
1

# 删除表里的数据


13760069-36674611a2b8bcae.PNG
2

# 查看binlog位置


13760069-a6916e07c95c58c0.PNG
3


13760069-6bbfe36f6b4e8b63.PNG
4

cat 4.sql

13760069-f229649c2a74ba9b.PNG
13760069-1340c00b066cacc7.PNG
5
13760069-10a4c2bcb2c7bf9b.PNG
6


13760069-acbcb0614d130977.PNG
7

(截取了部分)

13760069-c4644bbee562f3aa.PNG
8

可以看到生成了跟上面标准SQL相反的SQL了,通过这些反向SQL可以进行误操的数据恢复。

比如我们想恢复delete命令之前的数据。


13760069-ecc725f28a263a56.PNG
9

最后一定不要忘记了这一步,很关键,不然数据无法导入
mysql -uroot -p'[email protected]' <roll_5.sql

完成查询下结果,发现数据已恢复

13760069-2c8ecdcf60470750.PNG

猜你喜欢

转载自blog.csdn.net/weixin_34029949/article/details/87115394