mysql备份恢复最佳实践
1、备份是DBA维护数据库的底线
2、物理备份（冷备：关库备份、热备：数据库正常打开进行备份，打开不一定意味着没用没有障碍 备份期间可能产生锁）
将数据文件备份出来
3、逻辑备份
将行数据备份出来
4、最佳实践要求：
1、物理备份为主，逻辑备份为辅
物理备份作为全部备份，逻辑备份主要为了满足一些表级别的备份
2、要降低备份对生产的影响
锁的影响，对于myisam表，备份没有任何办法保证来降低锁的影响，对于innodb表来说，物理备份和逻辑备份都可以采取一些技术手段来降低锁的影响，锁的影响可以很小
3、备份会涉及到大量的物理读写，对于生产主要是物理读
对于7*24小时业务系统来说，采取将备份卸载到从库的方式或者采取限流的备份方式，
对于非7*24小时业务系统来说，采取备份卸载到从库的方式或者并行备份加快备份速度，防止备份时间延续到业务时间
4、注意备份对内存以及网络的影响
备份会占用大量的文件系统缓存，这些缓存会影响数据量对内存的使用，产生大量swap系统会很慢，影响生产
最好是把备份卸载到从库
5、备份一定要满足恢复要求，恢复要求就是使用备份恢复数据库花费的时间，备份方案的核心需求就是恢复时间要求
如何缩短恢复时间：加大全备的频率，数据恢复最不可控的时间就是binlog的恢复时间
6、恢复场景设计，不同的恢复场景需要不同的备份方案，恢复永远是最后手段 （贮备切换一定注意传输延迟带来的数据丢失和应用延迟带来的回复时间）
存储介质损坏，物理层面无法恢复
主备切换、追补binlog;使用物理备份进行恢复，回复戒指以及服务器需要强大的写入能力和网络传输能力
服务器损坏,新的服务器挂载存储介质
换上新的数据库装mysql，编辑配置文件指向正确的datadir，不要初始化！！
只要innodb，myisam，ibdata，redo，undo都在就可以正常启动
也可以贮备切换
文件系统或者分区损坏或者raid损坏
可以找专业数据恢复公司进行文件和分区的恢复或者主备切换
某些表文件的损坏，没有必要进行全部恢复，可以根据业务场景进行快速处理，主要看这个表数据的一些使用场景
表不小心被drop，truncate，dml
redo损坏，ibdata损坏，数据字典损坏
mysql备份原理
1、myisam引擎
锁表，备份，解锁，binlog 不管是物理还是逻辑，锁定时间长
2、inndob引擎
物理备份：备份文件 ibdata 表 undo 备份期间产生的redolog
极短时间的锁定（全库级别的锁定）flush table with read only 长事务可能造成锁定失败
1、如果有select正在执行，锁定会被挂起
2、dml如果正在执行，锁定会被挂起
3、对于未提交事务，不会被提交或者锁定
4、锁定一旦成功，dml不能执行，事务不能提交
redo apply ，回滚，binlog
mysqldump --single-transaction
逻辑备份使用 --single-transaction 整个备份期间使用mvcc特性保证一致性，可以不锁表，binlog追加
xtrabackup备份过程
1、开始备份，物理拷贝下述文件
ibdata,ibd,frm,undo
2、记录开始备份那个时刻开始的所有的redo，收集备份
3、等到上述文件备份完成，加锁flush table with read only 加锁成功的条件就是加锁的那个时刻数据库上面不能有正在执行的sql，包括select，可以有未提交事务
备份完成以后会有三类文件：备份文件/redo/备份元数据
4、加锁成功后，flush缓存，将剩余redo写入到备份文件中，将redo备份文件封装
5、将整个备份期间的元数据写入到备份元数据文件中
6、可选将备份期间的redo追加到备份文件中，同时回滚备份文件中未提交事务，整个过程会更新备份元数据
7、如果数据库需要恢复，只需要将备份文件进行还原 xtrabackup copy back 然后进行追加binlog，追加binlog的起始位置参考备份元数据中的info信息
备份元数据最核心信息：是否redo apply// 是否会滚//binlog恢复起点
备份语法
1、命令指定备份位置innobackupex --user=root --password=""--no-timestamp /backup/
2、apply log，默认会自动回滚未提交事务
3、能够读懂Xtrabackup_binlog_info文件
binlog_pos:开始恢复时的binlog 位置
4、启用压缩、加密、并行、限流
压缩 加密 占用大量cpu
并行 占用io
5、恢复数据库命令
6、追加binlog
备份常见问题
1、备份会因为加锁的问题，导致备库一段时间不可用
2、回复的时候，追加binglog因为没有正确的指定binlog起始位置，导致恢复过程报错
3、备份过程导致内存耗尽，产生swap影响生产
4、备份将网络带宽耗尽，影响生产
5、备份将io耗尽影响生产
增量备份
只是备份上次备份以后发生改变的数据
好处大大降低备份的数据量
增量备份一定要做一件事情，增备完成以后马上进行增量apply+redo only只是往里应用不回滚，相当于进行了一次全备
并不能降低物理读的数据量
增量被分的命令相对复杂，全备，增量，增量追加，最后一次增量追加
作业：
设计一个备份方案
增加一个备份从库
一周一个备份周期，周一全备、每天增量
监控备份和apply时候成功（每天读一下info）
设计一个一键恢复脚本
恢复一个误操作的表：truncatetable t1 ；使用备份恢复回来
innodb逻辑备份mysqldump
1、备份期间不锁表，使用undo mvcc特性来保证备份的一致性
2、需要手工记住备份完成以后对应的binlog，使用 flush log 来做一个起始标志
3、备份可能会导致undo增加很快
4、mysqldump不适合全部备份，一般用来备份表
5、对于一些非常核心的表，除了全备以外，最后定期做一下基于表的mysqldump
6、掌握mysqlbinlog追加恢复的命令指定其实结束位置
MySQLbinlog --start-position=120 --stop-position=564 MySQLserver.000003 > a.sql
跑binlog：
[root@root backup_binlog]# cat a.SQL |mysql
MySQLbinlog --start-position=120 --stop-position=564 MySQLserver.000003 |mysql
7、掌握mysqlbinlog解析日志，找到误操作的起始位置，例如drop table 或者truncate table
8、逻辑备份中select into ，load data，mysqldump将数据备份成独立的数据文件，指定分隔符
9、克隆从库，使用slave-info，来记录change master to 位置