MySQL数据库的备份和恢复
备份和恢复（数据）
备份：
存储的数据副本
原始数据持续改变
恢复：
把副本应用到线上系统
仅能恢复至备份操作时刻的数据状态
时间点恢复：
binary logs
为什么备份？
灾难恢复：硬件故障（冗余）、软件故障（bug）、自然灾害、黑客攻击、误操作、测试
备份时应该注意事项
能容忍最多丢失多少数据；
恢复数据需要在多长时间内完成；
需要恢复哪些数据；
做恢复演练：
测试备份的可用性；
增强恢复操作效率；
备份需要考虑因素
锁定资源多长时间？
备份过程的时长？
备份时的服务器负载？
恢复过程的时长？
备份什么？
数据
二进制日志、innodb的事务日志；
代码（存储过程、存储函数、触发器、事件调度器）
服务器的配置文件
备份的分类
1）从物理与逻辑的角度，备份可以分为物理备份和逻辑备份。
1》物理备份：对数据库操作系统的物理文件（如数据文件、日志文件等）的备份。物理备份又可分为脱机备份（冷备份）和联机备份（热备份）。
2》逻辑备份：对数据库逻辑组件（如表等数据库对象）的备份，也就是从数据库导出数据另存在一个或多个文件中。
2）从数据库的备份策略角度，备份可分为完全备份、差异备份和增量备份。
1》完全备份：
每次对数据进行完整的备份
对整个数据库的备份、数据库结构和文件结构的备份。保存的是备份完整时刻的数据库，是差异备份与增量备份的基础。
优点：备份与恢复操作简单方便
缺点：数据存在大量的重复，占用大量的空间，备份与恢复时间长
2》差异备份：
仅备份自上一次完全备份以来变化的那部数据
备份的时间节点是从上次完整备份起，备份数据量会越来越大。
恢复数据时，只需恢复上次的完全备份与最近的一次差异备份。
3》增量备份：
仅备份自上一次完全备份或增量备份以来变化的那部数据
以上次备份或上次的增量备份的时间为时间点，仅备份这之间的完整备份起到最后一次增量备份依次恢复，如中间某次的备份数据损坏，将导致数据的丢失。
3）按备份的数据集的范围：
完全备份和部分备份
完全备份：整个数据集；
部分备份：数据集的一部分，比如部分表；
4）根据数据服务是否在线
冷备份：
是在关闭数据库的时候进行的。
热备份：
数据库处于运行状态时进行的，这种备份方法依赖于数据库的日志文件。
读写操作均可进行的状态下所做的备份，MyISAM不支持热备，InnoDB支持热备。
温备份：
数据库锁定表格（不可写但可读）的状态下进行的。
备份策略
全量+差量 + binlogs
全量+增量 + binlogs
备份策略机制：
xtrabackup：
全量+差异+binlog
全量+增量+binlog
mysqldump：
全量+binlog
逻辑备份工具，基于mysql客户端协议
完全备份、部分备份；
innodb：热备或温备；
myisam：温备；
二次封装工具：
mydumper
phpmyadmin
一致性
数据的一致性
通常指关联数据之间的逻辑关系是否正确和完整。
数据库的一致性
通常指数据库从一个一致性状态变成另一个一致性状态
保持数据的一致性
1》备份开始时对所有表加锁，在备份结束之前不能修改数据库，这样做保持数据不变且一直处于同一个一致状态中，明显的缺点就是不能对数据库进行写操作。
2》在备份开始是对所有数据进行一个快照，快照记录的是开始备份那一刻所有数据的样子，所以在快照范围内的读取的数据具有一致性。
备份时保证所有备份操作放在一个事务中，且将事务隔离级别设为“可重读”，备份只是读取操作而没有更新操作所以不会出现“幻读”，所以数据对某个时间点来说就是一致的。
注：当事务处于可重读隔离级别时，并不意味着此时快照已经建立，而是当事务中第一查询语句执行时，快照才会建立。mysql为我们提供了个可以启动可重读事务的语句：start transaction with consistent snapshot
备份工具1：mysqldump（重要）
1）介绍：
mysqldump 是采用SQL级别的备份机制，它将数据表导成 SQL 脚本文件，在不同的 MySQL 版本之间升级时相对比较合适也是最常用的备份方法。
mysqldump是mysql服务自带的逻辑备份工具，能实现完全和部分备份，不支持增量备份。
mysqldump针对innodb类型的可以热备，针对myisam类型的可以温备：
2）备份原理：
通过协议连接到mysql数据库，将需要备份的数据查询出来并转换成对应的insert语句。
当我们需要还原这些数据时，就只需执行这些insert语句，就可将对应的数据还原。
3）优点：
可直接使用文本处理工具对备份数据进行处理。
4）缺点：
因为其过程是读取-转换-插入，没有索引等信息，所以还原后需要重建索引。
当数据为浮点型时，会出现精度问题。
备份过程为串行化，不能并行备份，所以速度慢，不适合数据量大时使用。
5）进行备份：
mysqldump [OPTIONS] database [tables] > /PATH/TO/BACKUP/NAME-DATE.sql # 备份单库，可以只备份其中的一部分表（部分备份）；
mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...] > /PATH/TO/BACKUP/NAME-DATE.sql # 备份多库；
mysqldump [OPTIONS] --all-databases [OPTIONS] > /PATH/TO/BACKUP/NAME-DATE.sql # 备份所有库；
将全量备份后，发生数据更改的二进制日志重定向到一个文件中
mysqlbinlog -j 245 bin-log.xxxxxxxx > /PATH/TO/BINLOG.sql
6）选项：
myisam存储引擎：
支持温备，备份时要锁定表；
-x, --lock-all-tables：锁定所有库的所有表，读锁；
-l, --lock-tables：锁定指定库所有表；
innodb存储引擎：
支持温备和基于事务进行热备；
--single-transaction：创建一个事务，基于此快照执行热备份；
解释：
使用上述选项后，mysqldump会自动将备份会话中的事务隔离级别设为可重读，并开启一个事务，且事务开启那一刻创建了快照，来保证一致性。
如果开启二进制日志，也定要设置--master-data选项。
7）其它，若无特殊情况，以下都需要一并添加：
-r, --routines：备份指定库的存储过程和存储函数；
--triggers：备份指定库的触发器；
-e, --events：事件表会被备份；
--master-data[=#]：是否添加二进制日志文件到输出
非0情况下都记录对应二进制日志文件位置
1：记录为change master to语句，此语句不被注释；
2：记录为change master to语句，此语句被注释，方便恢复时进行时间点的恢复；
--flush-logs：锁定表完成后，即进行日志刷新操作；
8）备份思路：
1>定期实施备份，指定备份计划或策略，并严格遵守
2>除了完全备份，开启msyql服务器的日志功能也是很重要的（完全备份加上日志，可以对mysql进行最大化压力）
3>使用统一和容易理解的备份名称，推荐使用库名或表名加上命令规则
9）备份数据的恢复
1>登录数据库进行恢复
1》使用管理员登录mysql
2》关闭当前会话的二进制日志记录
set sql_log_bin=off;
原因：
因为备份文件的格式就是些insert的语句，所以恢复数据时会执行大量的insert操作，这些操作会被记录到二进制日志中，所以为避免大量日志记录就需关闭二进制日志记录。但记得恢复完后再次开启。
3》执行source 备份的sql脚本路径
mysql>source /PATH/TO/BACKUP/NAME.sql
4》时间点恢复
备份时所在时间点之后的数据恢复就需要通过二进制日志来进行。
1——从二进制日志中提取时间点之后对应的sql语句。开启位置为备份时刻的位置，结束位置差不多为进行数据库恢复时刻的位置，特别要注意语句的特性。
2——对提取的sql语句进行操作。
mysql>soure BINLOG.sql
or
mysql -uroot -p< BINLOG.sql
2>不登录进行恢复，一般用于脚本
1》关闭二进制日志记录
2》执行sql脚本恢复
mysql -u用户名 -p[密码] < 库备份脚本的路径
mysql -u用户名 -p[密码] 库名 < 表备份脚本的路径
示例：
1》备份myisam表
mysqldump -uuser_name -ppassword --default-character-set=utf8 --opt --extended-insert=false --triggers -R --hex-blob -x db_name > db_name.sql
2》备份innodb表
mysqldump -uuser_name -ppassword --default-character-set=utf8 --opt --extended-insert=false --triggers -R --hex-blob --single-transaction db_name > db_name.sql
3》如果想要实现在线备份，还可以使用 --master-data 参数来实现
mysqldump -uuser_name -ppassword --default-character-set=utf8 --opt --master-data=1 --single-transaction --flush-logs db_name > db_name.sql
它只是在一开始的瞬间请求锁表，然后就刷新binlog了，而后在导出的文件中加入change master 语句来指定当前备份的binlog位置，如果要把这个文件恢复到slave里去，就可以采用这种方法来做。
注意：–extended-insert 需要根据实际情况决定是否启用或关闭 ，会对数据恢复速度产生较大影响。
4》使用mysql客户端来还原
mysql -uuser_name -ppassword db_name < db_name.sql
5》用source语法来还原，这个也是mysql客户端提供的功能
SOURCE /tmp/db_name.sql;
这里需要指定文件的绝对路径，并且必须是 mysqld 运行用户(例如 nobody)有权限读取的文件。
备份工具2：xtrabackup（重要）
1）介绍
xtrabackup由percona提供，是个开源的物理备份工具。
xtrabackup支持对innodb进行热备，全量备份、增量备份和差量备份。
xtrabackup支持对myisam进行温备，全量备份，备份myisqm表时会提前添加读锁。
xtrabackup和mysqldump一样都需要通过协议连接到mysql服务器，都是客户端工具，连接之后读取并复制innodb底层的”数据块”，完成“物理备份”。
2）备份原理
1》物理备份的原理
innodb存储引擎的逻辑单元从大到小分别是：
tablespace（表空间），segment（段），extent（区），page（页），row（行）
每个大的逻辑单元包含N个小的逻辑单元。
数据存于row中，row存于page中，备份时就是读取page并进行备份的。
2》增量备份的原理
每个page都有自己的LSN号码，LSN是一个全局递增的号码。当每次对page中的记录进行修改时，都会在page中记录本次有LSN，且这个号码会越来越大。
xtrabackup就是通过LSN来实现对innodb表进行增量备份的。每次备份开始时，会记录下当前备份到的LSN，当下线进行增量备份时，就会备份大于上次记录的LSN的page。
备份中的LSN大于当前page中的，说明这个page自从上次备份够后没有进行修改，反之，则就是进行了修改。
3》备份恢复整个过程
xtrabackup备份开始时，会同时进行两个线程。
一个是负责备份innodb中的page，另个是负责备份innodb的事务日志（redo log）。
那么备份结束后会得到两份文件，一份是不可用的备份文件，一份是事务日志。
page的备份就是物理备份和增量备份，之所以被认为不可用，是因为有一部分不确定的数据是可能存在与事务日志中的，且热备过程中数据也是可能会发生变化的，而事务备份就是这部分不确定数据的的备份。
所以我们恢复过程中需要通过这两个文件制作成一份可用的备份，而这个制作过程也就是“prepare”，为恢复工作做准备。
备份开始时，有些事务已经存在于事务日志中，这些日志可能已经提交但还没有同步到数据文件中，那么这部分事务日志就需要在prepare过程中就需要replayed（重放）。
而有些事务可能还未提交，这部分未提交的就需要在prepare过程中roolback（回滚）。
在有增量备份的情况下进行preparee恢复准备，是需要把所有增量都合并到之前的全量上，而这时只需要将已经提交的事务同步到数据文件即可，未提交的事务就不同进行回滚了。
这是因为增量备份时，这些事务可能已经提交了，只需要在最后一份增量上对未提交的事务回滚。
再进行细分些，xtrabackup对innodb类的是做热备，对myisam类的做温备。
温备过程是需要对表添加读锁的，所以温备的表数据是一致的，而在实际中数据库往往是两个类型都存在的，所以备份过程中是以myisam的一致性时间点作为最终备份的一致性时间点的。
这样我们就能想到，在备份时是先备份innodb存储引擎的数据，之后再进行备份其他包括myisam存储引擎的数据。
而在备份恢复时的prepare过程中，就只操作innodb类的数据即可，prepare完成后，所有数据的一致性时间点是相同的。
3）xtrabackup的版本和安装
xtrabackup的2.3版本前是有两个主要备份工具xtrabackup（C程序）和innobackupex（perl脚本）。
xtrabackup只能备份innodb和xtradb的表，而innobackupex都可以进行备份，但两个运行是会导致bug。
xtrabackup的2.3版本及其之后还是两个工具但都是C程序，作用还和以前一样，所以一般使用innobackupex命令进行备份。
可能在2.4版本后只保留xtrabackup。
安装时，需要从官方下载，有源码和rpm包，会依赖到很多包，所以提前配置好yum的base和epel源仓库。
https://www.percona.com/downloads/XtraBackup/LATEST/
percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm
4）xtrabackup全量备份和恢复
备份：
innobackupex --default-file=/PATH/TO/DEFAULT --host=ID ADDR --user=USER_NAME -P PASSWORD /PATH/TO/BACKUP
--default-file：指定备份时，从那个配置文件中读取配置信息。默认是使用的mariadb-libs的/etc/my.cnf，此时可以不写
--host：指定数据库服务ip地址。默认为localhost，此时可不写
--user：指定连接数据库服务的用户。默认为root，此时可不写
-p：指定用户密码，登录mysql时用的密码
/PATH/TO/BACKUP：备份文件存放目录
注意：
completed OK！字样，有它才说明备份成功，innobackupex会把备份过程完整输出到屏幕。
binlog备份，全量备份或机器毁坏后的操作备份，时间点备份
mysqlbinlog -j 245(N) bin-log.xxxxxxxx > /PATH/TO/BINLOG.sql
备份后的目录文件
在你所指定的备份目录下可以找到以当前时间命令的备份文件
[root@localhost backup]#ls
2017-11-18_19-39-17
[root@localhost backup]#ll 2017-11-18_19-39-17/
total 18460
-rw-r----- 1 root root 417 Nov 18 19:39 backup-my.cnf
-rw-r----- 1 root root 18874368 Nov 18 19:39 ibdata1
drwxr-x--- 2 root root 4096 Nov 18 19:39 mysql/
drwxr-x--- 2 root root 4096 Nov 18 19:39 performance_schema/
drwxr-x--- 2 root root 78 Nov 18 19:39 Syslog/
-rw-r----- 1 root root 19 Nov 18 19:39 xtrabackup_binlog_info
-rw-r----- 1 root root 113 Nov 18 19:39 xtrabackup_checkpoints
-rw-r----- 1 root root 448 Nov 18 19:39 xtrabackup_info
-rw-r----- 1 root root 2560 Nov 18 19:39 xtrabackup_logfile
文件介绍
backup-my.cnf：
此文件中包含my.cnf中的设置信息，只包含了备份时需要的信息。
ibdata1：
这是个innodb的共享表空间文件
xtrabackup_binlog_info:
此文件记录了备份开始时二进制日志文件的位置（position）
xtrabackup_checkpoints:
此文件记录此次备份属于那种类型的备份等信息
xtrabackup_info:
此文件记录了备份的概要信息
xtrabackup_logfile
此文件记录了备份过程中的日志，在对数据进行prepare时需要通过日志将数据还原成一致的可用备份数据
查看备份情况
cat /backup/2017-11-18_19-39-17/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1947282
last_lsn = 1947282
compact = 0
recover_binlog_info = 0
恢复：
在需要还原的服务器上安装xtrabackup。
把备份的整个目录拷贝到需要还原的服务器上。
两个服务器上的mysql版本需要相同（不相同的没试过）
prepare：
innobackupex --apply-log /PATH/TO/BACKUP/dir-quan
--apply-log：将目录中的日志应用到备份数据中
--use-memory=N：默认为100M，若备份数据量大且有足够的空闲内存时，可以用来指定大小的内存来工作，单位可以使用G,M....。
注意：
completed OK！字样
开始恢复：
确保服务停止
systemctl stop mariadb
数据目录必须为空目录
rm -rf /PATH/TO/DATADIR/*
数据目录一般为/var/lib/mysql/
恢复
innobackupex --datadir=/PATH/TO/DATADIR/ --copy-back /PATH/TO/BACKUP/dir-quan
修改权限
chown -R mysql: /PATH/TO/DATADIR/
启动服务
systemctl start mariadb
注意：
实际还原时，最好将对应的配置文件也都还原，也就是把原服务器上的配置拷贝下，确保配置还是原来的。
上述恢复并没有进行时间点的还原，实际工作中，需要进行。
时间点恢复，binlog恢复
mysql>soure BINLOG.sql
or
mysql -uroot -p< BINLOG.sql
5）xtrabackup增（差）量备份及恢复
全量备份是差量备份与增量备份的基础。
差量备份只能针对上一次全量备份。
增量备份可以针对上一次任务一种备份。
通俗地来说：所有增量备份加到一起就是差量备份了。
增量和差量备份都是针对innodb表来说的，对myisam表来说即使执行了增量备份，其实也是全量备份。
注意：以下常说成增量，大家注意增量和差量间的区别就行。
增（差）量备份：
innobackupex -pPASSWORD --incremental /PATH/TO/BACKUP --incremental-basedir=/PATH/TO/BACKUP/last-backup-file
--incremental /PATH/TO/BACKUP：表示本次备份是一个增量备份（若针对的上次备份为一个全量备份，这里也可以认为是个差量备份）
--incremental-basedir=/PATH/TO/BACKUP/last-backup-file：指定本次增量备份针对的是那个备份（可以是上个增量，也可以是上个全量）
binlog备份，增量备份或机器毁坏后的操作备份，时间点备份
mysqlbinlog -j 245 bin-log.xxxxxxxx > /PATH/TO/BINLOG.sql
查看备份情况
cat /backup/2017-11-20_03-43-15/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1947282
to_lsn = 2073366
last_lsn = 2073366
compact = 0
recover_binlog_info = 0
cat /backup/2017-11-20_03-51-32/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 2073366
to_lsn = 2084330
last_lsn = 2084330
compact = 0
recover_binlog_info = 0
恢复：
在需要还原的服务器上安装xtrabackup。
把备份的整个目录拷贝到需要还原的服务器上。
两个服务器上的mysql版本需要相同。
prepare：
对全量备份做准备工作
innobackupex --apply-log --redo-only /PATH/TO/BACKUP/dir-quan
--redo-only：表示进行准备（应用日志）工作时，只进行redo操作，只会重做已提交但未应用的事务，不会回滚未提交的事务。原因是后面还有个增量备份，未提交的可能在后面增量备份时进行提交。
对增（差）量备份做准备工作
innobackupex --apply-log [--redo-only] /PATH/TO/BACKUP/dir-quan --incremental-dir= /PATH/TO/BACKUP/dir-zeng
--redo-only：若只有一个增量备份或是最后那个增量备份文件，那么不需要这个选项，原因同上。也就是说这个选项不能用于最后一个增量备份进行prepare。
--incremental-dir=：此选项对应的目录为增量备份文件的目录
查看prepare情况
若不是对最后一个增量备份进行prepare，那么查看全量备份文件中的xtrabackup_checkpoints，可看到log-applied，LSN有所变化，可以和增量备份对比下。
cat /backup/2017-11-18_19-39-17/xtrabackup_checkpoints
backup_type = log-applied
from_lsn = 0
to_lsn = 2073366
last_lsn = 2073366
compact = 0
recover_binlog_info = 0
若是以及对最后一个增量备份进行了prepare，那么查看全量备份文件中的xtrabackup_checkpoints，可看到full-prepared，LSN有所变化
cat /backup/2017-11-18_19-39-17/xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 2084330
last_lsn = 2084330
compact = 0
recover_binlog_info = 0
注意：
prepared中可以使用--user-memory=选项来加快速度，前提是你有空闲的内存可用。
--redo-only这个选项需要多加注意，它不能用于最后那个增量备份的prepared，且必须用于其他增量备份的prepared。原因是后面还有增量备份的，未提交的可能在后面增量备份时进行提交。
开始恢复：
确保服务停止
systemctl stop mariadb
数据目录必须为空目录
rm -rf /PATH/TO/DATADIR/*
数据目录一般为/var/lib/mysql/
恢复
innobackupex --datadir=/PATH/TO/DATADIR/ --copy-back /PATH/TO/BACKUP/dir-quan
修改权限
chown -R mysql: /PATH/TO/DATADIR/
启动服务并查看是否恢复
systemctl start mariadb
注意：
实际还原时，最好将对应的配置文件也都还原，也就是把原服务器上的配置拷贝下，确保配置还是原来的。
上述恢复并没有进行时间点的还原，实际工作中，需要进行。
时间点恢复，binlog恢复
mysql>soure BINLOG.sql
or
mysql -uroot -p< BINLOG.sql
其他备份工具
1）mysqlhotcopy：几乎冷备
它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 来快速备份数据库。它是备份数据库或单个表的最快的途径，但它只能运行在数据库文件（包括数据表定义文件、数据文件、索引文件）所在的机器上。mysqlhotcopy 只能用于备份 MyISAM，并且只能运行在类Unix 和 NetWare 系统上。
1》mysqlhotcopy 支持一次性拷贝多个数据库，同时还支持正则表达。
示例：
mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name /tmp (把数据库目录 db_name 拷贝到 /tmp 下)
mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name_1 ... db_name_n /tmp
mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name./regex/ /tmp
注意，想要使用 mysqlhotcopy，必须要有 SELECT、RELOAD(要执行 FLUSH TABLES) 权限，并且还必须要能够有读取 datadir/db_name 目录的权限。
2》mysqlhotcopy 备份出来的是整个数据库目录，使用时可以直接拷贝到 mysqld 指定的 datadir 目录下即可，同时要注意权限的问题。
示例：
cp -rf db_name /usr/local/mysql/data/
chown -R nobody:nobody /usr/local/mysql/data/ (将 db_name 目录的属主改成 mysqld 运行用户)
2）select语句：
备份：select cluase into outfile 'filename';
恢复：create table
导入：load data
3）cp和tar
直接打包数据库文件，如.../mysql/data或/var/lib/mysql
备份
tar -Jcf mysql_all-$(date +%F).tar.xz /需要备份文件的路径/需备份的文件
模拟数据丢失
mv /var/lib/mysql/* /bak
数据恢复
cd /var/lib/mysql
tar -xf mysql_all-???.tar.xz
4）基于lvm2的备份：
快照（请求一个全局锁），之后立即释放锁，达到几乎热备的效果，物理备份；
注意：不能仅备份数据文件，要同时备份事务日志。
前提：要求数据文件和事务日志位于同一个逻辑卷。
前提：要求数据文件和事务日志位于同一个逻辑卷；
(1）请求锁定所有表；
mysql> flush tables with read lock;
(2) 记录二进制文件事件位置；
mysql> flush logs;
mysql> show master status;
mysql -e 'show master status;' >> /path/to/some_pos_file
(3) 创建快照卷
lvcreate -l # -s -p r - snam-name /dev/vg-name/lv-name
(4) 释放锁
mysql> unlock tables
(5) 挂载快照卷，并执行备份，备份完成后删除快照卷；
(6) 周期性备份二进制日志；
binlog
mysql的binlog间接实现增量备份
1）msyql增量备份概念
使用mysqldump进行完全备份，备份的数据中有重复数据，备份时间与恢复时间长。
而增量备份就是备份自上次备份之后增加或改变的文件或内容。
mysql没有提供直接的备份方法，可以通过mysql提供的二进制日志（binary logs）间接实现增量备份。
二进制日志保存了所有更新或者可能更新数据库的操作。
增量备份的特点：
没有重复数据，备份量不大，时间短
恢复麻烦，需要上次完全备份及完全备份之后所有的增量备份才能恢复，而且要对所有增量备份进行反推恢复。
2）mysql增量备份的实现
二进制日志在启动mysql服务器后开始记录，并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件。
所以只需定时执行flush logs方法重新创建新的日志，生成二进制文件序列，并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份。
cat /etc/my.cnf |grep max_binlog_size
要进行mysql增量备份，首先就是要确保开启二进制日志功能。
1》在mysql主配置文件my.cnf中[mysqld]项中加入log-bin=/文件存放路径/文件前缀，如log-bin=mysql-bin，然后重启mysql的服务。实际上默认此配置存在。
[mysqld]
log-bin=mysql-bin ##最好写绝对路径
2》使用mysqld --login-bin=/文件存放路径/文件前缀，重启mysql的服务，每周选择服务器负载较轻的时间段，或者用法访问较少的时间段进行备份。
3）mysql增量备份恢复
1》应用场景
人为的sql语句破坏了数据库，在进行下一次全备之前发生系统故障导致数据库数据丢失，在主从架构中，主库数据发生了故障。
2》增量恢复的方法
1>一般的恢复：
备份的二进制日志全部恢复
mysqlbinlog [--no-defaults] 二进制日志文件
2>基于时间点的恢复：
便于跳过某个发生错误的时间点实现数据恢复
从日志开头截至到某个时间点的恢复：
mysqlbinlog [--no-defaults] --stop-datetime='年-月-日 小时：分钟：秒' 二进制日志
从某个时间点到日志结尾的恢复：
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时：分钟：秒' 二进制日志
从某个时间点到某个时间点的恢复：
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时：分钟：秒' 二进制日志 --stop-datetime='年-月-日 小时：分钟：秒' 二进制日志
3>基于位置的恢复：
可能在同一时间点既有错误的操作也有正确的操作，基于位置进行恢复更加精准。
mysqlbinlog --stop-position='操作 id' 二进制日志
mysqlbinlog --stop-position='操作 id' 二进制日志
