备份类型：
完全备份
部分备份：仅备份其中的一张表或多张表
增量备份：仅备份从上次完全备份或增量备份之后变化的数据部分
热备份：在线备份，读写操作不受影响
温备份：在线备份，读操作可继续进行，但写操作不允许
冷备份：离线备份，数据库服务器离线，备份期间不能为业务提供读写服务
物理备份：直接复制数据文件进行的备份
逻辑备份：从数据库中“导出”数据另存而进行的备份
MyISAM: 支持温备，不支持
InnoDB: 既能热备又能温备
备份什么：数据、额外的数据（二进制日志和InnoDB的事务日志）、代码（存储过程和存储函数、触发器、事件调度器等），服务器配置文件
备份时需要考虑的因素：
持锁的时长
备份过程时长
备份负载
恢复过程时长
备份方案：完全备份+增量备份
备份方案之备份工具的选择：
mysqldump：完全备份，通过备份二进制日志实现增量备份（InnoDB热备和温备，MyISAM温备）注意数据库大于1GB的话不推荐这种备份，因为还原时间会过长
xtrabackup:对InnoDB：热备，支持完全备份和增量备份，对MyISAM：温备，只支持完全备份
补充：以下操作都在centos6上进行
Usage: mysqldump [OPTIONS] database [tables]
mysqldump -uroot --database hellodb > /tmp/hellodb.sql（单个数据库文件备份）
注意这种方式对MyISAM和InnoDB只支持温备，先要锁定备份的数据库，如果不锁定备份的同时有写入数据的操作，会导致恢复时数据不一致
在实际生产环境中一定要加一个-l参数，表示对单个数据库进行备份时，锁定此数据库的所有表，-x当对所有数据库备份时锁定所有数据库的所有表
所以使用方式应该是这样： mysqldump -uroot -l --database hellodb > /tmp/hellodb.sql
对InnoDB要支持热备的话：mysqldump -uroot --single-transaction --database hellodb > /tmp/hellodb.sql（只有
在开始备份那一刻时已经存在的数据会被备份，备份过程中新加入的数据不会被备份，InnoDB内部有每个数据的时间戳，如果时间戳
大于备份开始时的时间，该数据就会被忽略。如果有数据被删除且被删除的时间戳大于备份开始时的时间，该数据就会在备份中被还
原。这样保证了所有数据的可靠性）
其他选项： -E, --events：备份指定库的事件调度器
-R, --routines：备份存储过程和存储函数
--triggers：备份触发器
但是这样备份过后，数据库进行了读写操作，当数据库奔溃后，只能还原到备份的时间点，后面的对数据库的操作不能还原，如果在上
面的命令中加入--master-data=2,就可结合二进制日志还原到奔溃前的时间点了，此参数的作用是会在备份的sql文件中加入一条数
据：（使用less命令查看sql文件）
MASTER_LOG_FILE备份那一刻二进制文件是哪个，MASTER_LOG_POS备份到了哪个位置
要还原到奔溃前的那一刻：
（1）mysqlbinlog --start-position=20434 (备份那刻起的二进制文件） > 某个目录下的sql文件
注意如果二进制日志产生了滚动，这需要多次使用mysqlbinlog将后面滚动的二进制日志导入到sql文件中
（2）还原前面备份的sql文件
（3）将第（1）步中的sql文件逐个还原，还原命令mysql -u用户 -p密码 < sql文件
所以在生产环境中真正要使用的备份命令类似：mysqldump -uroot --all-databases --single-transaction --master-data=2 > /tmp/all.sql
补充：mysqldump做的备份，数据还原时也会产生二进制日志，这些日志是不需要的，使用mysql> SET SESSION sql_log_bin=0
命令关闭二进制日志，登陆mysql，使用source /path/somefile.sql依次还原， 还原后再开启二进制志SET SESSION
sql_log_bin=1
接下来说说怎么使用xtrabackup：www.percona.com上有该软件的下载（此处我下载的是centos6的rpm包）
yum -y install epel-release (xtrabackup有些依赖的包在epel源中）
yum -y install percona-xtrabackup-2.3.4-1.el6.x86_64.rpm
查看生成了哪些包
使用xtrabackup对innodb做热备，为了使xtrabackup的某些功能能够实现（即对单张表备份本文不做介绍），得先在mariadb的配置文件中开启一个参数innodb_file_per_table=ON 在配置文件中定义，这个参数的作用是把innodb的单张表存储为单个的文件
首先对整个数据库进行全库备份： innobackupex --user=root --password='' /root/backup/
在备份的文件中找到xtrabackup_checkpoints这个文件，less xtrabackup_checkpoints
backup_type = 说明此次备份是完全备份还是增量备份 full-backuped 表示完全备份，看到最后的completed ok就表示备份成功
了：
现在只需根据以前的数据库创建一个全新的空数据库和一个跟原始数据库相同的配置文件，保证数据目录为空
还原之前首先得对原来备份的文件进行整理，使用命令：innobackupex --apply-log /root/backup/2016-04-27_05-25-45/，最
后同样要看到completed ok 才表示整理完毕，再去查看xtrabackup_checkpoints文件：
backup_type = full-prepared，整理完毕
还原前要先停掉mariadb，使用还原命令： innobackupex --copy-back /root/backup/2016-04-27_05-25-45/，同样要看到
completed ok才算还原成功，注意我是使用默认的root用户还原的，因此数据目录所属的用户组和用户都是root，使用chown -R
mysql.mysql ./* 将属组和用户都改为mysql（不然mariadb会启动不了）
使用xtrabackup做增量备份，同样跟上面一样先执行一次完全备份，执行增量备份命令：
innobackupex --incremental /root/backup/ --incremental-basedir=/root/backup/2016-04-27_06-37-51
--incremental 指定增量备份的存储位置 --incremental-basedir 基于哪个备份文件做增量备份
还原的时候，先去整理完全备份innobackupex --apply-log --redo-only /root/backup/2016-04-27_06-37-51/
补充：当mariadb使用Innodb存储引擎时会使用内存中的一段空间取名叫做buffer pool，是mariadb用来存储产生的事务（包含已提
交和未提交的事务），所有内存中的事务都会被立即记录到磁盘中的事务日志文件中 数据库奔溃或终止时产生一个结果：提交的事务可
能只保存在内存当中，但没有同步到磁盘文件中去，当mariadb重启时会根据磁盘中的事务日志文件自动将已提交的事务同步到磁盘文
件中去，未能正常提交的事务做回滚操作 使用inobackupex备份时，内存中的事务（包括已经提交的事务和未提交的事务）也会被记
录下来，当使用xtrabackup还原时会将已提交的事务同步到磁盘文件中去，未能正常提交的事务做回滚操作，做增量备份时第一次完
全备份未提交的事务不应该回滚，因为到最后增量备份还原时此前未提交的事务可能已经提交了因此上面--redo-only的作用就是只“重
放”已经提交的事务，将已提交的事务同步到磁盘文件，而不做回滚操作
整理第一次增量备份：innobackupex --apply-log /root/backup/2016-04-27_06-37-51/ --incremental-dir=/root/backup/2016-04-27_06-42-59/
每次对增量的整理时前面都得先是完全备份的目录，然后才是增量备份的目录
我这里只做了一次增量备份，如果有多次增量备份只有最后一次整理不用--redo-only,也就是最后一次整理把所有未提交的事务都回滚
最后的还原#innobackupex --copy-back /root/backup/2016-04-27_06-37-51/ （最后指定的目录是完全备份的目录）
这就是使用xtrabackup对整个数据库进行备份
补充：如果要还原到某个时间点（比如奔溃前的时间点）还得借助二进制日志
更正：buffer pool 不只缓存事务，还缓存其他数据
