1.备份的原因
运维工作的核心简单概括就两件事:
1）第一个是保护公司的数据.
2）第二个是让网站能7*24小时提供服务(用户体验)。
1）备份就是为了恢复。
2）尽量减少数据的丢失（公司的损失）
2.备份的类型
冷备份:
这些备份在用户不能访问数据时进行，因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是，对于某些应用程序，会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。
温备份:
这些备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。
热备份:
这些动态备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。
3.备份的方式
逻辑备份
1）binlog
2）into outfile
mysql> select * from world.city into outfile '/tmp/world_city.data';
3）mysqldump
4）replication
物理备份:
基于数据文件的备份
1）Xtrabackup（percona公司）
4.备份策略
1）全量备份 full
2）增量备份 increamental
5.备份工具
1）mysqldump（逻辑）
mysql原生自带很好用的逻辑备份工具
2）mysqlbinlog（逻辑）
实现binlog备份的原生态命令
3）xtrabackup（物理）
precona公司开发的性能很高的物理备份工具
备份工具使用
mysqldump的备份
mysqldump常用参数
1）连接服务端参数(基本参数)：-u -p -h -P -S
2）-A, --all-databases：全库备份
[root@db01 ~]# mysqldump -uroot -poldboy123 -A > /backup/full.sql
3）不加参数：单库、单表多表备份
[root@db01 ~]# mysqldump -uroot -poldboy123 db1 > /backup/db1.sql
[root@mysql-db01 backup]# mysqldump -uroot -poldboy123 world city > /backup/city.sql
4）-B：指定库备份
[root@db01 ~]# mysqldump -uroot -p123 -B db1 > /backup/db1.sql
[root@db01 ~]# mysqldump -uroot -p123 -B db1 db2 > /backup/db1_db2.sql
5）-F：flush logs在备份时自动刷新binlog（不怎么常用）
[root@db01 backup]# mysqldump -uroot -p123 -A -R –triggers -F > /backup/full_2.sql
6）--master-data=2：备份时加入change master语句0没有1不注释2注释
[root@db01 backup]# mysqldump -uroot -p123 --master-data=2 >/backup/full.sql
7）-d：仅表结构
8）-t：仅数据
备份额外扩展项
1）-R, --routines：备份存储过程和函数数据
2）--triggers：备份触发器数据
[root@db01 backup]# mysqldump -uroot -p123 -A -R --triggers > /backup/full_2.sql
mysqldump特殊参数
1）-x：锁表备份（myisam温备份）
2）--single-transaction：快照备份
[root@db01 backup]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 –single-transaction>/backup/full.sql
mysqldump特殊参数
1）-x：锁表备份（myisam温备份）
2）--single-transaction：快照备份
[root@db01 backup]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 –single-transaction>/backup/full.sql
3)gzip:压缩备份
[root@db01 ~]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 –single-transaction|gzip>/backup/full.sql.gz
mysqldump的恢复
#先不记录二进制日志
mysql> set sql_log_bin=0;
#库内恢复操作
mysql> source /backup/full.sql
#库外恢复操作
[root@db01 ~]# mysql -uroot -p123 < /backup/full.sql
注意：
1）mysqldump在备份和恢复时都需要MySQL实例启动为前提
2）一般数据量级100G以内，大约15-30分钟可以恢复（PB、EB就需要考虑别的方式）
3）mysqldump是以覆盖的形式恢复数据的
企业故障恢复案例
背景：
正在运行的网站系统，MySQL数据库，数据量25G，日业务增量10-15M。
备份策略：
每天23：00，计划任务调用mysqldump执行全备脚本
故障时间点：
上午10点开发人员误删除一个核心业务表，如何恢复？
思路：
1）停业务避免数据的二次伤害
2）找一个临时的库，恢复前一天的全备
3）截取前一天23：00到第二天10点误删除之间的binlog，恢复到临时库
4）测试可用性和完整性
5）开启业务前的两种方式
a.直接使用临时库顶替原生产库，前端应用割接到新库
b.将误删除的表单独导出，然后导入到原生产环境
6）开启业务
故障模拟演练：
准备数据：
全备：
[root@db01 ~]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 --single-transaction|gzip > /backup/full_$(date +%F).sql.gz
模拟数据变化：
模拟故障：
恢复过程：
1）准备临时数据库
[root@db02 ~]# mysqld_safe --defaults-file=/data/3307/my.cnf &
2）拷贝数据到新库上
[root@db02 ~]# scp /backup/full_2018-08-16.sql.gz root@10.0.0.52:/tmp
2）拷贝数据到新库上
[root@db02 ~]# scp /backup/full_2018-08-16.sql.gz root@10.0.0.52:/tmp
3）解压全备数据文件
#进入tmp目录
[root@db02 ~]# cd /tmp/
#解压全备数据文件
[root@db02 tmp]# gzip -d full_2018-08-16.sql.gz
截取二进制
#查看全备的位置点（起始位置点）
[root@db02 tmp]# head -50 full_2018-08-16.sql |grep -i 'change master to'
#找到drop语句执行的位置点（结束位置点）
mysql> show binlog events in 'mysql-bin.000017';
#截取二进制
[root@db01 tmp]#mysqlbinlog -uroot -p123 --start-position=268002 --stop-position=671148 /application/mysql/data/mysql-bin.000017 > /tmp/inc.sql
#发送增量数据到新库
[root@db01 tmp]# scp /tmp/inc.sql root@10.0.0.52:/tmp
在新库内恢复数据 #不记录二进制日志
mysql> set sql_log_bin=0;
#恢复全备数据
mysql> source /tmp/full_2018-08-16.sql
#进入backup库
mysql> use backup
# 查看表
mysql> show tables;
#恢复增量数据
mysql> source /tmp/inc.sql
#查看表
mysql> sh
4）将故障表导出并恢复到生产
#导出new表
[root@db02 ~]# mysqldump -uroot -p123 -S /data/3307/mysql.sock backup new > /tmp/new.sql
#发送到生产库
[root@db02 ~]# scp /tmp/new.sql root@10.0.0.51:/tmp/
#进入backup库
mysql> use backup
#在生产库恢复数据
mysql> source /tmp/new.sql
#查看表
mysql> show tables;