mysql全量备份与增量备份
1.全量备份
全量备份就是把数据库中所有的数据进行备份。
备份所有库：
mysqldump -uroot -p456 -S /data/3306/mysql.sock -F -A -B |gzip >/server/backup/mysqlbak_$(date+%F).sql.gz
备份一个库：
mysqldump -uroot -p456 -S /data/3306/mysql.sock -F -B oldboy|gzip >/server/backup/mysqlbak_$(date+%F).sql.gz
2.增量备份
从上次全备之后，到下次全备之前更新的新数据。对于mysql来说，binlog日志就是mysql的增量数据。
1）按天备份
| 周一00点全量备份 | 周二00点全量备份 |
| 01.sql.gz | 02.sql.gz |
| 周一增量备份 | 周二增量备份 |
|
mysql-bin.000021 mysql-bin.000022 mysql-bin.000023 ... |
mysql-bin.000035 mysql-bin.000036 mysql-bin.000037 ... |
优点：
恢复时间：短，维护成本：低
缺点：
占用空间：多，占用资源：多，经常锁表影响用户体验
2）按周备份
| 周六00点全量备份 | ||
| 01.sql.gz | ||
| 周一增量备份 | 周二增量备份 | 周三增量备份 |
|
mysql-bin.000021 mysql-bin.000022 mysql-bin.000023 ... |
mysql-bin.000035 mysql-bin.000036 mysql-bin.000037 ... |
mysql-bin.000043 mysql-bin.000044 mysql-bin.000045 ... |
优点：
占用空间：小，占用资源：少，无需锁表用户体验相对好
缺点：
恢复时间：长、复杂，维护成本：高
3.从企业的角度看全量和增量
1）对于中小公司，全量一般每天一次，在业务量低估时执行全备并锁表；
2）对于单台数据库如何实现增量。利用rsync（配合定时任务频率高点，或者inotify主从复制）把所有binlog备份到远程服务器。但是尽量还是要做主从复制！
3）对于大公司，有可能会做周备，其他时间都是增量；
4）一主多从，会有一个从库做备份，延迟同步；
>>>需要mysql的mysqldump全量备份场合：
迁移或升级数据库；
增加从库的时候；
由于硬件或异常情况导致的主库或从库宕机，主从可互相切换，无需备份；但是由于人为操作导致主库误删，主从都会执行，此时需要备份；
做跨机房灾备，需要全量备份到异地。
>>>需要mysql的增量恢复场合：
人为操作导致主库误删（如drop），主从都会执行，此时需要增量备份；
只有一个主库的情况下需要增量恢复。
4.实战----模拟操作失误导致数据丢失进行恢复的过程
>>>思路一：
mysql -uroot -p456 -S /data/3306/mysql.sock
mysql> use oldboy
mysql> show tables;
mysql> select * from student;
mysql> quit
date -s '2018/10/05'
history |grep mysqld
mysqldump -uroot -p456 -S /data/3306/mysql.sock -F -B --master-data=2 oldboy|gzip >/server/backup/bak_$(date+%F).sql.gz #假设现在是00点，一般全量备份只要指定为master-data=2，master-data的作用就是为拿到开始恢复的位置点，以便后面的增量备份有所依据，其他全备已存在不用更新；建立从库才需要指定master-data=1告诉从库从主库的哪个位置进行更新，只需做全备无需增量备份。最好记录切割前的mysql-bin位置点（可以通过锁表看下master.info中记录的信息）
mysql -uroot -p456 -S /data/3306/mysql.sock
mysql> use oldboy
mysql> desc student;
mysql> insert into student(name) values('oldboy101');
mysql> insert into student(name) values('oldboy102'); #模拟00点到早上10点的增量
mysql> select * from student;
mysql> drop database oldboy; #模拟早上10点做的误操作，应用开始出现故障
mysql> quit
通过防火墙禁止web等应用向主库写数据或者主库锁表，让主库暂时停止更新，进行数据恢复
ll /server/backup
gzip -d bak_2018-10-05.sql.gz
grep -i "change" bak_2018-10-05.sql #如果先前忘记查看位置点，可以尝试在此找到，假设为000014
mysqladmin -uroot -p456 -S /data/3306/mysql.sock flush-logs #刷新binlog，将恢复的目标定到上步找到的位置，下面一个binlog则是新产生的了
cd /data/3306/
cp mysql-bin.000014 /server/backup/
cd /server/backup/
mysqlbinlog -d oldboy mysql-bin.000014 >bin.sql
vi bin.sql 将drop database oldboy这句删掉，并保存文件
mysql -uroot -p456 -S /data/3306/mysql.sock
mysql -uroot -p456 -S /data/3306/mysql.sock <bak_2018-10-05.sql
mysql -uroot -p456 -S /data/3306/mysql.sock oldboy <bin.sql
mysql -uroot -p456 -S /data/3306/mysql.sock
mysql> use oldboy
mysql> select * from student; #发现恢复成功
{补充：
mysql> show variables like '%log_bin%'; #有个参数sql_log_bin，如果关掉此参数，则利用mysqldump进行恢复的时候，就不会记录新的binlog日志mysql-bin.000015中}
>>>思路二：
1）停止一个从库，然后在主库刷新binlog，把mysql-bin.000014恢复成bin.sql（去掉drop语句的）
2）把全备bak_2018-10-05.sql及10点前的增量bin.sql恢复到从库
3）此时数据丢失多少？10点刷新binlog以后的数据，即mysql-bin.000015
4）停止主库，快速把mysql-bin.000015解析为SQL，恢复到从库 #避免主键冲突问题，尽量使停库时间缩到最短，尽量减少应用停止的时间
5）切换到从库提供服务
>>>增量恢复小结：
人为SQL造成的误操作；
需准备全备和增量；
恢复时建议对外停止更新；
恢复全量，然后把增量日志中有问题的SQL语句删除，恢复数据库
>>>增量恢复的核心思想：
流程制度控制，否则将面临服务和数据故障的风险；
可以通过延迟备份来解决，或者通过监控，或者通过制定黑、白名单（where子句）机制来控制；
选择停库修复，定义可量化的目标，满足业务需求的最低限制
5.mysqlbinlog增量备份
作用：解析mysql的binlog日志 #mysql-bin.0000XX，mysql-bin.index记录了所有mysql-bin文件
mysql内部增删改查等对mysql数据库有更新记录的文件，即mysql-bin文件
-d 指定单独的数据库恢复 #适用于对单个库做了误操作，只需恢复此库的备份恢复操作
--start-position --stop-position 指定位置恢复 mysqlbinlog mysql-bin.000020 --start-position=365 --stop-position=456 -r pos.sql
--start-datetime --stip-datetime 指定时间点恢复 mysqlbinlog mysql-bin.000020 --start-datetime='2018-10-06 15:00:00' --stop-datetime='2018-10-06 15:09:00' -r time.sql
【思考】
>>mysql出现同步延迟原因是什么？如何解决？
当主库的TPS并发较高时，产生的DDL(修改类的sql语句)数量，超过了slave机器sql线程所能承受的能力，那么延时就会产生了。
>>解决方式
数据库的读写分离软件，mysql-proxy和amoeba；
了解mysql高可用MMM技术；
mysql半同步应用，xtrabackup物理备份；
mysql+heartbeat+drbd高可用；
2018年11月2日
祝好！
