mysqlbinlog恢复数据注意事项【转】
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 信息，那么可以不使用该参数，使用或者不使用都可以恢复成功。
转自
mysqlbinlog恢复数据注意事项 – UnixFBI 运维特工 http://www.unixfbi.com/499.html
</div>
<div class="postDesc">posted @ <span id="post-date">2018-07-23 11:05</span> <a href="https://www.cnblogs.com/paul8339/">paul_hch</a> 阅读(<span id="post_view_count">233</span>) 评论(<span id="post_comment_count">0</span>) <a href="https://i.cnblogs.com/EditPosts.aspx?postid=9353587" rel="nofollow">编辑</a> <a href="#" onclick="AddToWz(9353587);return false;">收藏</a></div>
</div>
<script type="text/javascript">var allowComments=true,cb_blogId=212575,cb_entryId=9353587,cb_blogApp=currentBlogApp,cb_blogUserGuid='183fadf7-909f-e411-b908-9dcfd8948a71',cb_entryCreatedDate='2018/7/23 11:05:00';loadViewCount(cb_entryId);var cb_postType=1;var isMarkdown=false;</script>