0. meta data lock实现（mysql 5.5后引入的）
http://blog.leokim.cn/2017/05/25/mysql-metadata-lockmdl/
1.分析muysqldump流程
2. 利用mysqldump做备份建一个从库（online不停业务）
3. 理解binary log在备份中的作用
4. 利用全备+binary log恢复到某个时间点
＝＝＝＝＝＝＝＝＝＝
5. 利用innobackupex 做备份及恢复 3307， 3306
6. 利用innobackupext做增备及恢复 3307， 3306
7. 利用innobackupex加binary log恢复到某个时间点
8. 表空间传输5.6， 5.5
扩展知识：
9. 关于mysql 5.5以下mysqlbinlog（第三方版本）的闪回
10. mysql binary logs格式浅析
DDL没办法在事务里保护
/usr/local/mysql/bin/mysqldump -S /tmp/mysql_3306.sock –master-data=2 –single-transaction leokim >leokim_1_full.sql
GTID下可以不要"–master-data=2"这个参数
more leokim_1_full.sql
人生就这么悲剧了，数据没了，这个时候就需要恢复
需要注意在dump的时候如果是gtid会有一个SET @@GLOBAL.GTID.PURGED 会直接报错
mysql -S /tmp/mysql_3306.sock leo_bak<leokim_1_full.sql
利用全备恢复 但是少了我们全备后添加的memcache
在全备文件里找到master_log_pos = 858
所以我们在binlog里找到858这个位置 恢复从这个位置开始 到truncate之间的数据就可以了
mysqlbinlog -v --base64-output=decode-rows --start-position=858 --stop-position=1149 mybinlog.000001 > 1_bak.sql
use leokim rename table leo to leo_bak; rename table leo_bak.leo to leo; select * from leo;
mysqlbinlog --start-position=858 --stop-position=1062 mybinlog.000001 | mysql -S /tmp/mysql_3306.sock
现在看mongodb就恢复出来了
如果开启了gtid 要reset master之后再做才行，gtid会认为自己已经做过了就不会恢复
所以恢复要找个别的地方恢复 然后再恢复到主库上 不能在主库上reset master
在测试库里回复完了单独做一次mysqldump 然后到出来放到生产库里恢复
gtid开启的话 要加上-f强制执行
或者加上–set -gtid-purged=OFF
有GTID的环境里做恢复特别要小心
binlog恢复一定要按顺序恢复不能跳着恢复