基本意义：
将数据另存到其他设备，以便于出现问题时恢复数据
为什么要备份：
灾难恢复；需求改变；测试
几个事先需要考虑的问题：
可以容忍丢失多长时间的数据？恢复要在多长时间内完成？是否需要持续提供服务？需要恢复什么：整个数据库服务器、单个数据库、一个或多个表？
备份类型：
根据是否需要数据库离线，可以分为：
冷备：cold
backup
关闭mysql服务，或读写请求均不允许；
温备：warm
backup
备份的同时仅支持读请求；
热备：hot
backup
备份的同时，业务不受影响，读写均支持；
根据要备份的数据范围，可以分为：
完全备份：full
backup，备份全部数据集；
增量备份：incremental
backup，上次完全备份或增量备份以来改变了的数据；
差异备份：differential
backup，上次完全备份以来改变了的数据；
组合备份：
完全+增量(二进制)+二进制日志
完全+差异(二进制)+二进制日志
根据备份数据或是文件，可以为分：
物理备份：直接备份数据文件
备份和恢复都比较简单；
恢复速度快；
逻辑备份：备份表中的数据和库代码；
优点：
恢复简单；
备份的结果为ASCII文件，可以编辑；
与存储引擎无关；
可通过网络备份和恢复；
缺点：
备份或恢复都需要mysqld服务器进程参与；
备份结果占据更多的空间；
浮点数可能会丢失精度；
还原之后，索引需要重建；
需要备份什么数据：
数据库数据；
数据库配置文件；
代码：存储过程、存储函数、触发器等；（如mysqldump
-E -R）E:event R:routines
Linux系统相关的配置文件；
二进制日志；
备份工具：
mysqldump:
逻辑备份工具
InnoDB热备、MyISAM温备
备份和恢复较慢；
mydumper:
多线程备份工具；
lvm-snapshot:
接近于热备的工具；
物理备份；
备份和恢复较快；
SELECT
INTO OUTFILE 导出
LOAD
DATA INFILE ‘‘ INTO TABLE tbname 导入
逻辑备份工具
快于mysqldump
ibbackup:
xtrabackup:
物理备份工具
InnoDB热备、MyISAM温备
速度快；
mysqlhotcopy:
几乎冷备
从备份中恢复需要的操作：
停止MySQL服务;
记录服务的配置和文件权限；
复制备份文件至数据目录；
按需调整配置；
按需改变文件权限；
尝试启动服务；
装载逻辑备份；
检查和重放二进制日志；
确定数据还原正常完成；
以完全权限重启服务器；
mysql备份工具之mysqldump的介绍-->
性质：MySQL客户端工具；
功能：备份整个服务器，单个或部分数据库，单个或部分表，表中某些行，存储过程，存储函数，触发器
能自动记录备份时的二进制日志文件及相应position；
-u
#username
-h
#hostname
-p
#password
--all-databases
#备份所有库
-B,
--databases dbname dbname
#多数据库备份
--lock-all-tables
#锁表，不可写，备份后，会自动解锁
#此参数关联的信息-->
mysql>
FLUSH TABLES WITH READ LOCK;
mysql>
UNLOCK TABLES;
--master-data=2
#记录备份时的二进制日志名和二进制日志位置，
0不记录，2仅注释到备份文件（CHANGE
MASTER TO MASTER_LOG_FILE和MASTER_LOG-POS）
#本文作用是为了方便差异和增量备份（实际都属于二进制日志备份），记录完全备份时二进制日志的位置及二进制日志的文件名
#此参数关联的信息-->
mysql>SHOW
MASTER STATUS; //查看当前binlog位置
#mysqlbinlog
--start-position=xxx --stop-position=xxx binlog_name >
file.sql //生成二进制日志备份文件
--single-transaction:
基于此选项能实现热备InnoDB表，不支持MyISAM；由此，不需要同时使用--lock-all-tables（既然热备，当然不需要锁表）；
一次完整的备份/恢复过程：
------------完全备份---------------------
#mysqldump
-uroot -pmypass --single-transaction --master-data=2 --all-databases >
/backup/all_db_`date +%F`.sql
#完全备份file1
------------数据库内容写入1--------------
******************************************
------------差异备份---------------------
#less
file1.sql
#找到备份时刻的binlog位置，提供差异备份时所需的起始binlog位置xxx1
mysql>
FLUSH TABLES WITH READ LOCK;
#锁表
mysql>SHOW
MASTER STATUS；
#查看此刻binlog位置，提供差异备份时所需的末端binlog位置xxx2
#mysqlbinlog
--start-position=xxx1 --stop-position=xxx2 binlog_name > file2.sql
#差异备份
mysql>UNLOCAK
READ;
------------数据库内容写入2--------------
******************************************
------------丢失的数据2备份--------------
#mysqlbinlog
--start-position=xxx2 binlog_name
#确定恢复到哪个位置，确定下xxx3
#mysqlbinlog
--start-position=xxx2 --stop-position=xxx3 binlog_name >
file3.sql
------------数据库内容恢复--------------
mysql>SET
sql_log_bin=0
#关闭二进制日志
mysql>source
#mysql
-uroot -p123456 < file1.sql
#完全备份恢复
#mysql
-uroot -p123456 < file2.sql
#增量备份恢复
#mysql
-uroot -p123456 < file3.sql
#出错的日志恢复
mysql>SET
sql_log_bin=1
mysql>FLUSH
PRIVILEGES;
依据二进制日志的备份，也可以切割日志，从而直接复制日志文件，再将切割后的日志文件直接导出为sql
mysql>flush
logs;
#滚动二进制日志
恢复后，开启mysql前，务必查看数据库文件权限Mysql备份工具之LVM快照机制：
特点:
几乎热备、物理备份
前提：
事务日志必须跟数据文件在同一个LV上；#对于innodb来说，就是tbname.frm和tbname.ibd，如果不在同一个lv上，则生成的两个快照可能时间不一致
备份前配置文件先加入参数sysc_binlog=1#即任何事务提交立即同步到二进制日志上，避免事物丢失过程：
备份过程：
mysql>
FLUSH TABLES WITH READ LOCK; #读锁表,执行之后不能退出mysql，退出会解锁
mysql>
FLUSH LOGS; #滚动日志，方便之后的二进制日志备份，如此以来，不用记录二进制日志的位置，因为滚动之后，会生成新的二进制日志
或
mysql> SHOW MASTER
STATUS; #记录快照备份时的二进制日志，便于恢复完全备份后到真正崩溃之间的操作
创建lv_snap-->切换一个新的终端来执行，不要退出终端
#lvcreate
-L 100M -n mylvsnap -p r -s /dev/mapper/myvg-mylv #为数据所在的卷创建快照（确认VG上是否有足够的空间）
#mount
-t ext4 /dev/mapper/mylvsnap /mylvsnap
#cp
/mylvsnap/* /backup/all_data_`date +%F`/ #复制快照内的数据库文件到备份目录
mysql>
UNLOCK TABLES; #解锁
利用快照卷恢复的时候，innodb可能会有一个崩溃恢复的过程，因为快照的时候，很有可能会快照了事务提交但未同步和事务未提交的二进制日志信息（这些信息日志有，但是数据库没有对应数据），所以innodb会认为数据库曾经崩溃过
恢复过程：
参考mysqldump的恢复过程