MySQL备份恢复之回顾总结

备份恢复总结回顾

备份
1.备份对生产的影响
（1）IO
（2）网络
（3）锁
为了减少这种影响，我们将备份卸载到从库

2.备份分为冷备和热备，对于互联网企业不接受冷备

3.热备又分为逻辑备份和物理备份
（1）逻辑备份
备份数据行
（1）SQL语句：执行脚本
（2）数据行 ：load data，恢复速度快
（2）物理备份
备份数据页
xtrabackup

4.恢复原理
备份+binlog
对于binlog
（1）跑到某一个点截止
（2）跑到最新
（3）编辑binlog，去除我们不需要或者刻意避免的SQL语句（drop table）

5.关于逻辑备份
（1）备份速度慢
（2）恢复速度慢
（3）使用到MVCC特性 --singe–transaction
（4）对于myisam需要全局锁表-x
困难点是知晓恢复binlog的起点
（1）如何知道binlog里面的日志包含的时间范围
（2）-F 切换binlog

对于数据库的升级和迁移常使用逻辑备份，因为备份出来的SQL语句是标准的，不同的版本是都可以跑标准的SQL语句，数据也是标准

如何实现逻辑备份的并行处理呢？
使用手工的分拆，实行库和表并行备份，并行恢复。例如对于40个表，10个大表，16颗CPU，对于10个大表启动10个备份线程

关于binlog执行的两种方式
1.mysqlbinlog … | mysql -uroot -p123
2.mysql -uroot -p123 < binlog.sql

对于binlog，我们要学会使用–start-position 和–stop-position进行日志的截取

6.物理备份的原理
（1）拷贝数据页
（2）myisam表来说，通过锁来实现数据的一致性
（3）innodb表来说，使用redolog来实现数据的一致性
（4）备份期间的redolog，applylog（备份完成以后马上可以进行applylog），rollback
（5）物理备份需要能够读懂各种info文件
（6）备份速度快，恢复相对比较容易（info文件的支持）
（7）并行，限流

增量备份
（1）在谁的基础上进行增量，可以全备和增量
（2）增量恢复的时候，只要没有和binlog对接，就一直使用redo-only，不要进行回滚，否则恢复失效
（3）在和binlog对接的时候，最好不要加上redo-only，实现自动回滚，如果加上了redo-only，也没有问题
（4）增量备份适合数据仓库系统，不是很适合在线交易系统

作业：实际一套带有全备和增量的备份系统，要求恢复增量不超过2次，尽量降低备份的数据量，备份实现自动化。
写出各个时间点的恢复方案，模拟一个删除操作，进行相应的恢复