备份的目的
能够防止由于机械故障以及人为误操作带来的数据丢失，例如将数据库文件保存在了其它地方。
备份的分类
以操作过程中服务的可用性分：
冷备份：cold backup mysql服务关闭，mysql离线
温备份：warm backup mysql服务在线，但是不允许写请求，例如 read lock，在线的某些功能需要中止。
热备份：hot backup 备份同时，业务读写请求继续，业务不受干扰。(没有绝对的热备份，无限接近，停止的时间忽略不计)
myisam ：不支持热备
innodb ： 需要专用工具
以操作方式区分：
逻辑备份： 备份的是建表、建库、插入等操作所执行SQL语句(DDL DML DCL)，适用于中小型数据库，效率相对较低(相对复杂，且在恢复过程中容易丢失数据，不推荐使用)
物理备份： 直接复制数据库文件，适用于大型数据库环境，不受存储引擎的限制，
但不能恢复到不同的MySQL版本。(推荐使用)
lvm快照备份的优缺点
优点：
几乎是热备 (创建快照前把表上锁，创建完后立即释放)
支持所有存储引擎
备份速度快
无需使用昂贵的商业软件(它是操作系统级别的)
缺点：
可能需要跨部门协调(使用操作系统级别的命令，DBA一般没权限)
无法预计服务停止时间
数据如果分布在多个卷上比较麻烦 (针对存储级别而言)
lvm 快照备份原理：
LVM对LV提供的快照功能，只对LVM有效。
当一个snapshot创建的时候，仅拷贝 原始卷 里数据的 元数据(meta-data)。因此建立快照的速度非常快
创建的时候，并不会有数据的物理拷贝，因此 snapshot的创建几乎是实时的，当原始卷上有写操作执行时，
snapshot 跟踪原始卷块的改变，这个时候原始卷上将要改变的数据在 改变之前被拷贝到 snapshot预留的空间里，
因此这个原理的实现叫做写时复制 (copy-on-write)。
在写操作写入块之前，将原始数据移动到 snapshot空间里，这样就保证了所有的数据在snapshot创建时保持一致。
而对于snapshot的读操作，如果是读取数据块是没有修改过的，那么会将读操作直接重定向到原始卷上，如果是要
读取已经修改过的块，那么就读取拷贝到snapshot中的块。
LVM 快照备份流程：
LVM快照： 锁表时间接近热备
1. 加全局读锁
mysql> flush tables with read lock;
2.创建快照， lvcreate -L 500M -s -n lv-mysql-snap /dev/datavg/lv-mysql ;
3.刷新二进制日志 mysql> flush logs
4 释放锁 mysql>unlock tables
5. 挂载 快照设备 ，并从快照设备中，对数据库文件进行打包与 压缩
6、卸载快照设备
7、 移除快照设备 lvremove -f /dev/datavg/lv-mysql-snap
产生了一份新的 二进制日志。
此时，手动插入 几条数据，修改几条数据 ======》 体现最新的 二进制日志中。！
模拟崩溃：
停止服务，删除 数据库所有文件 ( 二进制日志不要和数据库数据放在同一目录 )
要求，恢复所有数据，包括 刚才 新增 和 修改了的 数据。
恢复流程：
1、恢复最近的一次 完全备份， mysql-2018-9-19-full.tar.gz /mysql 解压。
2、将最近的一份二进制日志 进行导出 mysqlbinlog /data/mysql-binlog/mysql.000025 > /tmp/a.sql
3、启动mysql服务(产生一份新的二进制日志 )，登录mysql
4、设置 临时 停止记录 二进制 日志。 mysql> set session sql_log_bin=0;
5、mysql> source /tmp/a.sql;
6、mysql> set session sql_log_bin=1; 重新开启二进制日志功能
至此，恢复完成！ 用 select 语句 进行 查询验证，看数据是否恢复 。
