mysqlbinlog 恢复数据注意事项

前言： 上次有个有个朋友恢复MySQL数据，一直恢复不成功，也没有报错信息，使用的环境是MySQL 5.7 使用了GTID以及binlog格式为ROW。现在我主要总结下没有恢复成功可能的原因以及解决方法。

1.不要使用base64-output=decode-rows参数

--base64-output=decode-rows
主要是解析ROW级别binlog日志时使用。 我们解析日志的时候都会使用：

# mysqlbinlog -v --base64-output=decode-rows --start-position=XXX --stop-position=XXX mysql-bin.0000XX 
复制

这是我们解析binlog日志时使用的命令，我们可以很直观的分析binlog日志。

但是我们想要恢复到数据库中的时候，不能使用 --base64-output=decode-rows
参数，否则是无法恢复到数据库的。

2.是否使用--skip-gtids=true参数

--skip-gtids=xxx
的作用为：mysqldump 是否使用 --skip-gtids=true
参数，要根据情况来定； 第一种情况： 如果我们是要恢复数据到源数据库或者和源数据库有相同GTID信息的实例，那么就要使用该参数。如果不带该参数的话，是无法恢复成功的。因为包含的GTID 已经在源数据库执行过了，根据GTID特性，一个GTID信息在一个数据库只能执行一次，所以不会恢复成功。

# mysqlbinlog --skip-gtids=true  mysql-bin.000012 |mysql -uroot -p
复制

或者

# mysqlbinlog --skip-gtids=true  mysql-bin.000012 > backup.sql
mysql -uroot -p < backup.sql
复制

第二种情况： 如果是恢复到其他实例的数据库并且不包含源实例的GTID信息，那么可以不使用该参数，使用或者不使用都可以恢复成功。

本文出自 “运维特工” 博客，转载请务必保留原文链接 和 http://www.unixfbi.com

您的阅读和关注就是对我们最大的鼓励与支持。请长按下面二维码关注“运维特工”公众号。

运维特工，战胜心魔！！