MySQL线上备份与恢复方案
一 全量备份和增量备份的优缺点
1.1 按天全备和按周全备份优缺点
1.1.1 按天全备优缺点：
优点：
>>按天全备恢复时间短
>>维护成本低
缺点：
>>占用空间大
>>占用资源多，比如CPU,还有锁表操作等
1.1.2 按周全备优缺点：
优点：
>>占用空间小
>>占用资源少
缺点：
>>按周全备恢复时间长，麻烦
>>维护成本大
====================================================
二 企业的方案
2.1 中小型公司
一天一次全备，在流量低的时候执行全备，执行前要锁表
单台数据库，如何增量？
用rsync 把所有binlog备份到远程服务器:
rsync-avz /usr/local/mysql/data/mysql-bin.00000*
[email protected]::backup--password-file
=/etc/rsync.password
2.2 大公司
一周做一次全备，每周六0点一次全量，下周六0点之前都
是增量。节省备份时间，减小备份压力；但是增量的bin
log文件副本太多，还原很麻烦。
2.3 一般企业都会一主多从，然后会有一个从库做备份
三 使用备份的场景
3.1数据库升级或者迁移
3.2增加总库
3.3人为的DDL 语句，所有库都会执行，这时候需要备份恢复
3.5跨机房灾备，需要备份拷贝
3.4因为硬件或者特殊情况，主从可以互相切换，这个时候
无需使用备份。
四 增量备份的必要前提
4.1 必须打开binlog
4.2 需要一个全备
4.3 全备之后到出问题时的增量binlog文件备份
五 增量恢复流程
首先通过防火墙禁止web等应用程序向主库写数据，让主库暂时
停止更新，然后在进行恢复。
5.1检查凌晨全备和binlog日志，检查全备里的从哪个binlog文
件
5.2导出全备数据
5.3把全被之后的增量全部移到另外的地方
5.4找到出问题时那个binlog，然后修改sql语句
5.4导入全量备份
5.5依次导入增量备份数据
六 binlog三种模式以及更改模式
binlog日志的三种模式
6.1statement level 模式
每一条修改数据的SQL都会记录到master的bin-log中，slave
在复制的时候sql进程会解析成个原来master执行过的相同的
SQL来再次执行
优点：不需要记录每一行的数据变化，减少了bin-log的日志
量,节约IO,提高性能
缺点：他还是需要记录每一条SQL语句执行的上下文信息,以
保证所有语句在slave执行的时候能够和master结果一样;另
外就是对于一些的额外的功能,比如存储过程,触发器,函数
的支持不是很好
6.2row level
日志会记录每一行数据被修改的模式，然后在slave上对相同
数据进行修改
优点：bin-log可以不记录执行的sql语句的上下文相关信息,
仅仅需要记录哪一条记录被修改了，修改成什么样了。所以
rowlevel的日志内容会非常清楚的记录每一行数据修改的细
节;不会出现某些特定情况下存储过程，函数挥着触发器无法
被正确复制的问题
缺点：所有的执行的语句当记录到日志的时候，都将以每行记
录修改来记录，这样可能会产生的日志内容。尤其Altertable
可能产生更多的内容。比如update语句可能一起更新了多行,
那么就产生了很多日志。
6.3Mixed 模式
statementlevel 和 rowlevel的结合,MySQL会根据执行的每一
条具体的SQL语句来区分对待记录的日志形式,也就是在state
ment和 row 之间选择一种;Statement还是和以前的一样，但是
row做了一些改变，比如alter 的时候使用statement模式,但是
在update或者delete操作的时候,还是记录所有行变更。
6.4调整binlog日志模式方法
配置文件修改：
log-bin=/usr/local/mysql/data/mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"
在线修改 立即生效：
SETSESSION binlog_format="STATEMENT"
SETSESSION binlog_format="ROW"
SETSESSION binlog_format="MIXED"