Mysql数据库的备份和恢复

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' 二进制日志